Environment
@sentry/cloudflare 10.69.0- Cloudflare Workflows
Problem
The Workflow completes successfully, but the Workers runtime subsequently reports:
The Workers runtime canceled this request because it detected that your Worker code had hung and would never generate a response.
Evidence
For one staging invocation:
workflow_complete: 2026-08-06T15:02:11.150Zfinalization_outcome: 2026-08-06T15:02:11.572Zworkflow_wrapper_outcome with final status SUCCESS: 2026-08-06T15:02:11.587Z- Workers runtime cancellation:
2026-08-06T15:02:13.572Z
The cancellation occurred approximately 1.985 seconds after the successful wrapper outcome, matching the 2-second Sentry flush timeout. Application work and finalization had completed; the cancellation followed Sentry teardown scheduled through waitUntil.
Issue #23005 identified a Workflow-instance reuse deadlock caused by capturing Sentry instrumented waitUntil. PR #23017 fixed that by using getOriginalWaitUntil(context). The post-success cancellation still occurs.
We are testing a local mitigation that awaits flushAndDispose(client) before the Workflow run() returns, instead of scheduling Sentry teardown through waitUntil.
Expected behavior
A successfully completed Workflow should not produce a later Workers runtime cancellation, while Sentry teardown remains safely flushed and disposed.
Please investigate whether Workflow instrumentation should await teardown, use a different lifecycle mechanism, or otherwise prevent Sentry teardown from being treated as hung by the Workers runtime.
Related: #23005, #23017
Environment
@sentry/cloudflare10.69.0Problem
The Workflow completes successfully, but the Workers runtime subsequently reports:
Evidence
For one staging invocation:
workflow_complete:2026-08-06T15:02:11.150Zfinalization_outcome:2026-08-06T15:02:11.572Zworkflow_wrapper_outcomewith final statusSUCCESS:2026-08-06T15:02:11.587Z2026-08-06T15:02:13.572ZThe cancellation occurred approximately 1.985 seconds after the successful wrapper outcome, matching the 2-second Sentry flush timeout. Application work and finalization had completed; the cancellation followed Sentry teardown scheduled through
waitUntil.Relationship to #23005 and #23017
Issue #23005 identified a Workflow-instance reuse deadlock caused by capturing Sentry instrumented
waitUntil. PR #23017 fixed that by usinggetOriginalWaitUntil(context). The post-success cancellation still occurs.We are testing a local mitigation that awaits
flushAndDispose(client)before the Workflowrun()returns, instead of scheduling Sentry teardown throughwaitUntil.Expected behavior
A successfully completed Workflow should not produce a later Workers runtime cancellation, while Sentry teardown remains safely flushed and disposed.
Please investigate whether Workflow instrumentation should await teardown, use a different lifecycle mechanism, or otherwise prevent Sentry teardown from being treated as hung by the Workers runtime.
Related: #23005, #23017