You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: