Fresh-runtime workflow poll can defect after queued cancellation

[schickling-assistant]

I found a case where queued cancellation resolves cleanly for the external task and for a long-lived worker-side projection, but a fresh-runtime pollWorkflow(...) call for the same execution fails with a RuntimeException defect.

Reproduction

https://github.com/schickling-repros/2026-04-effect-workflow-poll-after-cancel

npm install
npm run repro

The repro uses:

• a temporary local Postgres instance
• a long-lived workflow worker
• a generic external task service with queued task submission and cancellation

Expected

After queued cancellation, a fresh-runtime pollWorkflow(...) call should resolve to the same terminal success that the worker-side projection sees.

Actual

The external task reaches terminal canceled, and the worker-side projection resolves the execution as terminal success with finalState: "canceled", but a fresh-runtime pollWorkflow(...) call for the same execution returns a failed result whose defect contains RuntimeException.

Versions

• effect: 3.21.0
• @effect/workflow: 0.18.0
• @effect/cluster: 0.58.0
• @effect/sql-pg: 0.52.1
• Node: v24.14.0
• OS: darwin-arm64

---

_{Filed by an AI assistant on behalf of @schickling}

[schickling-assistant]

Validated the public repro twice locally. It reproduces deterministically on the current repo state at https://github.com/schickling-repros/2026-04-effect-workflow-poll-after-cancel (commit 486a2556f9b42c9fd2e72ae0bdca07fb36c28435). The failure remains the same: the external task reaches terminal canceled, the worker-side projection resolves finalState="canceled", and a fresh-runtime pollWorkflow call returns a failed result with a RuntimeException defect.\n\nOne caveat: the repro emits expected bootstrap SQL noise from @effect/cluster about cluster_shards / cluster_migrations on startup, but that does not change the outcome.