🐛 Workflows: caught waitForEvent timeout emits false "Worker code had hung" cancellation

[matthew-gizmo]

Summary

A standalone deployed Workflow reproduces a Workers runtime cancellation after a waitForEvent() timeout is caught and the Workflow run() method reaches its end. The HTTP API request succeeds, but the Workflow invocation is logged as:

The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.

The repro has no Sentry, RPC, queues, Durable Objects, waitUntil(), or application imports.

Reproduction

Deployed repro:

https://workflow-timeout-repro.gizmo-ai.workers.dev

1. Run the timeout case:

curl 'https://workflow-timeout-repro.gizmo-ai.workers.dev/?mode=timeout'

2. The request returns HTTP 200 with a Workflow instance ID.
3. The Workflow waits for an event with a one-second timeout. No event is sent.
4. The timeout is caught, the Workflow logs repro timeout caught, then logs repro workflow finished.
5. The Workers logs then contain the cancellation above.

For comparison, this case sends the matching event after 100 ms and completes without the cancellation:

curl 'https://workflow-timeout-repro.gizmo-ai.workers.dev/?mode=event'

Minimal repro

export class TimeoutWorkflow extends WorkflowEntrypoint<Env, Params> {
 async run(_event: WorkflowEvent<Params>, step: WorkflowStep): Promise<void> {
 try {
 await step.waitForEvent('repro wait', {
 type: 'workflow-timeout-repro-event',
 timeout: '1 second',
 });
 console.log('repro event received');
 } catch (error) {
 console.log('repro timeout caught', error);
 }

 console.log('repro workflow finished');
 }
}

The fetch handler only creates the Workflow instance and returns JSON. The deployed worker is a standalone reproduction; its source can be provided privately if needed.

Expected behavior

Once the waitForEvent() timeout rejects, the rejection is caught and run() returns normally. The Workflow should complete without a runtime hung-request cancellation.

Environment

• Deployed Worker: workflow-timeout-repro
• Compatibility date: 2026-08-06
• Cloudflare Workflows on Workers
• Reproduces on the deployed runtime; the event-success path is clean

Could this be a timeout-cleanup issue where waitForEvent() leaves a pending resolver, event listener, or other promise associated with the Workflow invocation after its timeout has been caught?

[matthew-gizmo]

We can correlate this with a production occurrence, but not with a meaningful application-code change:

Timeline (UTC)

• 2026-07-27 20:41:02 — Release workflow started for release release-2026-07-27-19.56-c12337f973.
• 2026-07-27 21:01:42 — The release's affected-worker plan saw workflows-production live at source SHA 776bca1077dd0ce7b48d537c1253f8e4de617371
• 2026-07-27 21:02:58 — deployment completed as Cloudflare version cd951f90-2416-4c18-812e-091d126bda93, tagged worker-workflows@c12337f9731a2d3d380c11fea6a0bc732d99b39b.
• 2026-07-27 23:10:05 — First matching production exception observed in the raw S3 Worker logs. We scanned the 20:00–22:59 UTC objects without finding this message; the first match was about 2h07m after the deployment.
• The S3 event is a worker_rpc / run exception with the same false “code had hung” cancellation message. The HTTP/workflow behavior otherwise completes as expected.

The Workflows Worker compatibility date in the deployed commit was 2026-05-26 and was not changed by this release. The direct workers/workflows diff from the previous release only changed a lint script; the Workflows waitForEvent handling itself was unchanged.

Our hypothesis is that this release/redeployment made the existing path run on a changed internal Workers/Workflows runtime, or otherwise exposed an internal runtime regression, rather than introducing the bug through application logic. Could you correlate Cloudflare's internal runtime/workerd rollout history for workflows-production around 21:02–23:10 UTC on 2026-07-27? In particular, was there an internal Workflows runtime change or rollout that would not be visible through the Worker version or compatibility date?

[NextifyLabs]

Possibly related data point from cloudflare/workers-sdk#14959.

Environment. wrangler 4.116.0, compatibility_date 2026-07-30, nodejs_compat, executionModel: "stateless", head_sampling_rate: 1.

We are seeing an identical false trigger:

The Workers runtime canceled this request because it detected that your Worker’s code had hung and would never generate a response.

but through a different Workflow path: returning a structured object from step.do(), rather than a waitForEvent() timeout.

We isolated that behavior in production with an A/B/A/B reversal test:

• object step result → 6/6 affected
• same result JSON-stringified across the step.do() boundary → 0/18 affected
• withdrawing the workaround reproduced the error immediately; reinstating it removed it again

The Workflow/user code finishes normally in both cases. Notably, we observed the error is emitted after the Workflow completes.

The potentially relevant part for this issue is that some affected invocations also emit:

An RPC result was not disposed properly. One of the RPC calls you made expects you to call dispose() on the return value, but you didn't do so.

We don’t know whether these are the same defect, since the triggers are clearly different, but both have the same overall shape: user code completes normally, followed by the same hung-request cancellation, with evidence in our case that some runtime-owned RPC/lifecycle state may remain attached to the invocation.

Similar to @matthew-gizmo, we had assumed our codebase might be problematic, but after testing, we believe the issue is caused by changes in the production Workers/Workflows environment.

Full reproduction details and reversal-test results are in cloudflare/workers-sdk#14959.