[showcase][approvals] Approving an Invoice Dual Sign-off request strands its flow run — `notify_cleared` resolves `{record.account.owner}` to nothing (possible regression of #7381)

[huangyiirene]

Symptom

Approving any flow:showcase_invoice_signoff approval request records the decision correctly — the request re-reads status:'approved' and an approve action row is appended — but the approver receives HTTP 500 RESUME_FAILED and the backing flow run re-reads status:'failed'. The engine error is:

> Node 'notify_cleared' failed: notify: at least one recipient is required, but every recipient template resolved to nothing: {record.account.owner}

The boot log carries the matching [approvals] resume failed — the run is stranded ERROR. The invoice therefore never reaches end_ok, and the "Notify: Cleared" message the demo promises is never delivered. Deterministic for every invoice approval.

⚠️ Possible regression of #7381, which is closed as completed (fixed by PR #7395 — "unstrand the Invoice Dual Sign-off approval demo, and the second instance of the same hop"). The node, the template, the engine message and the stranded-run symptom are identical, and it reproduces on framework a86db175. Worth confirming whether the fix regressed, was never merged into this branch, or covered only the sibling instance.

Root cause

examples/app-showcase/src/automation/flows/index.ts — InvoiceDualSignoffFlow. The notify_cleared node declares recipients: ['{record.account.owner}'] while the flow's start node declares no config.expand, so record.account is the raw scalar FK id and the relation hop resolves to nothing. The engine's own diagnostic already names both candidate fixes: add the relation to the start node's config.expand so the engine hydrates it, or address a scalar the trigger record already carries.

Reproduction

1. Boot examples/app-showcase on framework a86db175.
2. Take any flow:showcase_invoice_signoff request — seeded INV-1008, or raise a fresh one by PATCHing a draft invoice to status:'sent'.
3. POST /api/v1/approvals/requests/…/approve as an entitled approver.

Observed: HTTP 500 RESUME_FAILED; sys_approval_request re-reads status:'approved' with the approve action row present; the flow run re-reads status:'failed'. Reproduced 2× on two separate invoices with a byte-identical error, plus the matching stranded-run ERROR in the boot log.

Source

Extracted from the QA run #7517 (framework a86db17, console 09987b68).

[huangyiirene]

Closing as a duplicate of #7381 — already fixed on main before this card was filed; the QA run re-found it because its build predates the fix.

Timeline, verified against GitHub rather than inferred:

• The QA build a86db175 (PR qa/checklist: result-issue-per-run + checklist-author/checklist-test skills + list-filename selector #7304 branch) was cut early on 2026-08-10 — the platform-core.seed-integrity run QA run · platform-core.seed-integrity · a86db175 · 2026-08-10 · PASS #7326 was already executing on it at 06:44Z.
• [showcase][approvals] Approving the Invoice Dual Sign-off demo strands its flow run — notify_cleared reads {record.account.owner} with no expand on the start node #7381 (same defect, same root cause, same error text: notify_cleared reads {record.account.owner} with no config.expand on the start node) was filed 08:19Z and fixed by PR fix(showcase): unstrand the Invoice Dual Sign-off approval demo, and the second instance of the same hop (#7381) #7395, merged 2026-08-10T10:03Z.
• fix(showcase): unstrand the Invoice Dual Sign-off approval demo, and the second instance of the same hop (#7381) #7395 also swept all 29 showcase flows for the same relation-hop class and fixed the one other live instance (showcase_task_done_notify_owner), with a real-kernel resume test suite and a reverse verification that reproduces [showcase][approvals] Approving the Invoice Dual Sign-off demo strands its flow run — notify_cleared reads {record.account.owner} with no expand on the start node #7381's toast verbatim.
• The approvals QA run (QA run · approvals (FULL area) · a86db175 · 2026-08-11 · 5 PASS / 2 PARTIAL / 1 FAIL #7517) executed against the pre-fix a86db175, so its 2/2 reproduction is consistent with the fix landing later, not evidence the fix failed.

One nuance worth keeping from #7395's implementation notes: the "add expand: ['account'] and keep {record.account.owner}" shape this card's report implies does not work — showcase_account has no owner field (the injected owner column is owner_id). The merged fix re-points the recipient at {record.owner} and keeps the hydration for {record.account.name}.

Residual for the next sweep, recorded on the run card rather than kept open here: re-run decision-only-via-service clause 2 on a build that includes #7395 to confirm the checklist item goes green.

---

Generated by Claude Code