egov-workflow-v2: transition silently drops the 'assignees' key — @JsonProperty("assignes") + lenient deserialization means no eg_wf_assignee_v2 rows

[ChakshuGautam]

Summary

The ASSIGN action updates the assignee column on the parent eg_wf_processinstance_v2 row but never inserts rows into eg_wf_assignee_v2. Any consumer that reads assignees from the join table — including /egov-wf/process/_search responses used for re-assignment and downstream auto-escalation — sees zero assignees for a complaint that was successfully assigned.

Reproduction (fresh, 2026-06-10, PGR on DIGIT 2.9-line stack)

1. Citizen files a PGR complaint; GRO performs ASSIGN with one assignee via /egov-workflow-v2/egov-wf/process/_transition (HTTP 200; the assignment is visible in the UI timeline).
2. Inspect the DB:

SELECT pi.action,
       (SELECT count(*) FROM eg_wf_assignee_v2 a WHERE a.processinstanceid = pi.id) AS join_rows
FROM eg_wf_processinstance_v2 pi
WHERE pi.businessid = '<SRID>' ORDER BY pi.createdtime;
-- APPLY  | 0
-- ASSIGN | 0   ← expected 1

3. A subsequent ProcessInstance search returns assignes: [] for the latest instance.

Impact

• Re-assignment flows that depend on current assignees mis-resolve.
• Auto-escalation (CCRS pgr-services scheduler) skips every assigned complaint with NO_ASSIGNEES — on a production Kenya deployment 100% of open complaints are unescalatable for this reason.
• Workaround we use in tests/demos: manual INSERT INTO eg_wf_assignee_v2 (...) for the ASSIGN process instance — clearly not viable for production.

References

• Downstream context: feat(pgr+configurator): escalation feature — OTEL-instrumented scheduler, /escalation/_trigger admin endpoint, configurator editor, embedded workflow designer, integration tests egovernments/Citizen-Complaint-Resolution-System#770 (design doc § "Assignee-persistence upstream bug") and discussion Design: CRS Escalation Feature (PR #770) egovernments/Citizen-Complaint-Resolution-System#773 (prompt 2).

[ChakshuGautam]

Root cause identified — correction to this report

Deeper investigation (verified live on two stacks plus code trace) shows the original framing of this issue is wrong in two ways, and the real bug is simpler:

1. The service persists assignees correctly — when it receives them. A transition carrying "assignes": [{uuid}] produces eg_wf_assignee_v2 rows for both state-changing and self-loop ASSIGN actions. The persister mapping (ProcessInstances.*.assignes.*) is fine.

2. The actual root cause is the misspelled API contract key + lenient deserialization. ProcessInstance.assignes is bound with @JsonProperty("assignes") (ProcessInstance.java). Spring Boot's default ObjectMapper has FAIL_ON_UNKNOWN_PROPERTIES disabled, so any client that sends the correctly spelled "assignees" key has it silently dropped — the transition succeeds with HTTP 200, the ProcessInstance row is written, and no assignee rows are inserted (the persister skips an empty extraction without error). Multiple real clients send the natural spelling; nothing at any layer warns.

3. Correction to my original text: "writes assignee to parent row" was wrong — eg_wf_processinstance_v2.assignee is a dead legacy column (superseded by eg_wf_assignee_v2 in the 2019 DDL migration) and is NULL on every row we inspected. The "self-loop drops assignees" perception comes from /process/_search returning the newest ProcessInstance per business id — the newest being the silently-assignee-less one.

Minimal fix (tested)

Add a deserialization alias so both spellings are accepted while serialization continues to emit "assignes" (keeping persister jsonPaths and all consumers unchanged):

@JsonProperty("assignes")
@JsonAlias("assignees")
private List<User> assignes = null;

We've applied exactly this in our deployment (fix branch based on the production commit; 311/311 unit tests, including new round-trip tests that fail without the alias and prove the silent drop). Happy to raise it as a PR if useful.

A worthwhile hardening alongside: log a WARN (not fail) when a transition arrives with null/empty assignees for an action whose resultant state has actionable roles — the silent-success path is what let this go unnoticed.

[ChakshuGautam]

Fix verified in production (Kenya deployment): with the @JsonAlias("assignees") patch deployed, an ASSIGN sent with the correctly-spelled key now writes eg_wf_assignee_v2 rows (verified by SQL — organic insert, not a manual fixup), /process/_search returns the assignee on the latest ProcessInstance, and a downstream auto-escalation consumed it end-to-end. Patch branch: fix/wf-assign-assignee-persistence (one line + 4 round-trip tests that fail without it).