fire scenario.planningAreaProtectedCalculation.submitted much earlier [MARXAN-1316] #866
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request is being automatically deployed with Vercel (learn more). marxan – ./app🔍 Inspect: https://vercel.com/vizzuality1/marxan/4Z7ME8a4FJdox5jWbUQTDPXYTzYF marxan-storybook – ./app🔍 Inspect: https://vercel.com/vizzuality1/marxan-storybook/5fQxm33m3crLWDt6C2nP6nsfoXar |
We did originally fire the event below in `CalculatePlanningUnitsProtectionLevelHandler.execute()`, however this would be *after* some potentially expensive SQL queries had been run in `ScenarioPlanningUnitsProtectedStatusCalculatorService.calculatedProtectionStatusForPlanningUnitsIn()`, which would lead is some cases to a very long delay between the time an API user submits a request for `POST /api/scenarios/:id/protected-areas` and the time a `scenario.planningAreaProtectedCalculation.submitted/v1/alpha` event shows up in the scenario status data. However, as we're moving the firing of this event across a couple of cqrs event boundaries, I am less confident that we would consistently fire a `finished` or `failed` event paired with this `submitted` one in case of any unexpected errors. So, long story short, if something starts breaking horribly in how we deal with these `planningAreaProtectedCalculation` events, we should reassess this: probably keeping the event firing here, but adding more appropriately robust error handling, if needed.
hotzevzl
force-pushed
the
chore/api/MARXAN-1316_fire-protected-percentage-calculation-submitted-event-earlier
branch
from
5a1b01b to
3a3f8c7
Compare
rubvalave
approved these changes
Feb 25, 2022
hotzevzl
deleted the
chore/api/MARXAN-1316_fire-protected-percentage-calculation-submitted-event-earlier
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://vizzuality.atlassian.net/browse/MARXAN-1316
We did originally fire the event changed in this PR in
CalculatePlanningUnitsProtectionLevelHandler.execute(), however this would be after some potentially expensive SQL queries had been run inScenarioPlanningUnitsProtectedStatusCalculatorService.calculatedProtectionStatusForPlanningUnitsIn(),which would lead is some cases to a very long delay between the time an API user submits a request for
POST /api/scenarios/:id/protected-areasand the time ascenario.planningAreaProtectedCalculation.submitted/v1/alphaevent shows up in the scenario status data.However, as we're moving the firing of this event across a couple of cqrs event boundaries, I am less confident that we would consistently fire a
finishedorfailedevent paired with thissubmittedone in case of any unexpected errors. So, long story short, if something starts breaking horribly in how we deal with theseplanningAreaProtectedCalculationevents, we should reassess this: probably keeping the event firing here, but adding more appropriately robust error handling, if needed.