feat(geoprocessing): protected-areas: geo extractor: emit api events

[kgajowy]

Substitute this line for a meaningful title for your changes

Overview

Please write a description. If the PR is hard to understand, provide a quick explanation of the code.

Designs

Link to the related design prototypes (if applicable)

Testing instructions

Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.

Feature relevant tickets

Link to the related task manager tickets

---

Checklist before submitting

• Meaningful commits and code rebased on develop.
• If this PR adds feature that should be tested for regressions when
  deploying to staging/production, please add brief testing instructions
  to the deploy checklist (docs/deployment-checklist.md)
• Update CHANGELOG file

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

marxan – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan/FD2miSBkBtimNJRSVPiiCwje9sdD
✅ Preview: https://marxan-git-geoprocessing-marxan-416-api-events-vizzuality1.vercel.app

marxan-storybook – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan-storybook/HNK4VqEEga1YZcHe7XtnUTjywmpN
✅ Preview: https://marxan-storybo-git-geoprocessing-marxan-416-api-events-v-9e81ca.vercel.app

[hotzevzl]

thanks @kgajowy.

Besides the minor naming suggestions, I wonder if we should use the data prop of these events to also include in the series of events (submitted/finished or failed) for each request a unique id that links them together, a sort of correlation id. Actually, maybe such correlation id should be a top-level column/prop for API events 🤔...

Probably we can get away without this at this stage - the main issue may be that if users submit two shapefiles for protected areas within a short timeframe and the first one is still processing while the second starts being processed, we may never know of a failure of the second one if the first one takes longer to complete processing and completes successfully (or variations thereof of similar timing issues).

If we feel we should handle these possible race conditions explicitly, we'd still need to handle these correlation ids in a meaningful way, of course.

[hotzevzl]

I suggest to use protected areas rather than (the more specific) wdpa term where relevant - I know our core db table for protected areas is called wdpa but in practice it's a table for protected area info, some (most in some cases?) of which happen to be from the WDPA source. We've discussed this with Alicia at some point in the past, though we have kept the wdpa table name and some other such references around.

Suggested change

	('project.wdpa.submitted/v1/alpha'),
	('project.wdpa.finished/v1/alpha'),
	('project.wdpa.failed/v1/alpha');
	('project.protectedAreas.submitted/v1/alpha'),
	('project.protectedAreas.finished/v1/alpha'),
	('project.protectedAreas.failed/v1/alpha');

[hotzevzl]

as above if accepting the previous suggestion

Suggested change

	`DELETE FROM api_event_kinds WHERE id like 'project.wdpa.%';`,
	`DELETE FROM api_event_kinds WHERE id like 'project.protectedAreas.%';`,

[hotzevzl]

and so on for the rest of the PR 😱 - best to cross check with @aagm that she is indeed happy with this suggestion 😃

[hotzevzl]

please double check the labels of these enum members - did you mean project__wdpa__finished__v1__alpha and so on? (or project__protectedAreas__finished__v1__alpha if replacing wdpa)

[kgajowy]

🤦 shame on me! thanks for catching this!

[hotzevzl]

same as in api service

[kgajowy]

thanks @kgajowy.

Besides the minor naming suggestions, I wonder if we should use the data prop of these events to also include in the series of events (submitted/finished or failed) for each request a unique id that links them together, a sort of correlation id. Actually, maybe such correlation id should be a top-level column/prop for API events 🤔...

Probably we can get away without this at this stage - the main issue may be that if users submit two shapefiles for protected areas within a short timeframe and the first one is still processing while the second starts being processed, we may never know of a failure of the second one if the first one takes longer to complete processing and completes successfully (or variations thereof of similar timing issues).

If we feel we should handle these possible race conditions explicitly, we'd still need to handle these correlation ids in a meaningful way, of course.

It sounds like a request tracing. If we would like to, consumer (or we at controller level) can assign some transaction-id which is attached to every track-able step (for example, logger in each step) so that we could track full request path.

We can add timestamp / uuid to job as well.

[kgajowy]

@hotzevzl fixed the above in 24066f0

[hotzevzl]

thanks @kgajowy.
Besides the minor naming suggestions, I wonder if we should use the data prop of these events to also include in the series of events (submitted/finished or failed) for each request a unique id that links them together, a sort of correlation id. Actually, maybe such correlation id should be a top-level column/prop for API events thinking...
Probably we can get away without this at this stage - the main issue may be that if users submit two shapefiles for protected areas within a short timeframe and the first one is still processing while the second starts being processed, we may never know of a failure of the second one if the first one takes longer to complete processing and completes successfully (or variations thereof of similar timing issues).
If we feel we should handle these possible race conditions explicitly, we'd still need to handle these correlation ids in a meaningful way, of course.

It sounds like a request tracing. If we would like to, consumer (or we at controller level) can assign some transaction-id which is attached to every track-able step (for example, logger in each step) so that we could track full request path.

We can add timestamp / uuid to job as well.

I think I overshot by using "correlation id" which indeed is used in request tracing - that's a useful thing to have in general, but here I mean only a way to correlate the ApiEvents related to the same file upload for a specific project. Only something to think about for the reasons/caveats I outlined in my comment, but not for this PR.

[Dyostiq]

@kgajowy it is not chore :D