Investigate if WF3 is idempotent

[AishaHassen]

Background

Duplicate DHIS2 events in the Capture app have been observed in the MSF LIME integration. WF3 is responsible for syncing data from OpenMRS to DHIS2, and the suspected root cause is that WF3 currently lacks upsert logic — meaning if the workflow runs more than once for the same data (e.g. on retry after failure), it will create duplicate events rather than updating existing ones.

Goal

Investigate whether WF3 is idempotent with respect to DHIS2 event creation, and confirm or rule out the lack of upsert logic as the cause of observed duplicates.

Investigation steps

1. Review WF3 job code and Check for deduplication logic — determine if WF3 queries DHIS2 for an existing event before attempting to create one, and whether any deduplication key (e.g. OpenMRS encounter UUID stored as a DHIS2 data element or event attribute) is used.
2. Reproduce the duplicate — re-run WF3 against the same OpenMRS payload and confirm whether a second event is created in DHIS2.

Expected outcome

• A clear determination of whether WF3 is idempotent.
• If not: identification of the specific step(s) where duplicate events are created.
• A recommendation for how to implement upsert logic (e.g. using a stable deduplication key from OpenMRS to query and conditionally update vs. create events in DHIS2).

Acceptance criteria

• WF3 code reviewed and insert vs. upsert behaviour documented.
• Duplicate reproduction confirmed or ruled out via test run.
• Root cause identified and documented in a comment on this issue.
• If WF3 is not idempotent: a follow-up issue is created to implement upsert/deduplication logic.

[mtuchi]

I will need sometime to reproduce the issue and isolate which forms create duplicate events and which forms are working as expected. I have added an estimate of 6