Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HeeftBetrekkingOpAndere handling should have dedicated and self-sufficient adapters for verwerkingssoort "I", "T" and "V" #485

Open
MLenterman opened this issue Dec 11, 2024 · 0 comments
Labels
refactor refactor

Comments

@MLenterman
Copy link
Collaborator

Currently verwerkingssoort "V" is handled by it's own dedicated adapter, but verwerkingssoort "I" and "T" are handled in a single adapter. Ideally they are both handled in their own adapters. Likely the handler adapter for "I" can do the validation and then call the handler for "T" if the gerelateerdeZaak is not present.

Furthermore the handler adapters should be self-sufficient and handle a single HeeftBetrekkingOpAndere from start to finish. Currently the handling of HeeftBetrekkingOpAndere are split into 2 phases. The first phase mutates the "other" zaak first for each HeeftBetrekkingOpAndere. The second phase then updates the "current" zaak in one go. Even though this is more efficient from a technical perspective, it also makes it not retryable and leaves the zaak in a unrecoverable messy inconsistent state when one of them throws an error. The handler adapters should update both the "other" zaak and the "current" zaak within the scope of the adapter. That does indeed mean that each HeeftBetrekkingOpAndere will trigger a patch zaak on "current" zaak.

Implementation suggestion:
HeeftBetrekkingOpAndere should be handled sequentially. A patch on "current" zaak returns the zaak after the patch has been applied. This could potentially be used when processing the next HeeftBetrekkingOpAndere. This saves a getZaak call for each HeeftBetrekkingOpAndere. Beware though. The handling adapters should have a fallback to do a getZaak anyways if the return from patch is not available. Otherwise, when one HeeftBetrekkingOpAndere fails, all following ones will fail too.

@MLenterman MLenterman added the refactor refactor label Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor refactor
Projects
None yet
Development

No branches or pull requests

1 participant