`Miniflare.dispose()` can delay or skip `workerd` termination behind earlier cleanup awaits

[teamleaderleo]

What versions & operating system are you using?

System:
OS: macOS 26.5.1
CPU: (10) arm64 Apple M5
Memory: 286.09 MB / 24.00 GB
Shell: 5.9 - /bin/zsh

Binaries:
Node: 22.23.1 - /Users/leoli/.nvm/versions/node/v22.23.1/bin/node
npm: 10.9.8 - /Users/leoli/.nvm/versions/node/v22.23.1/bin/npm
pnpm: 10.33.0 - /Users/leoli/.nvm/versions/node/v22.23.1/bin/pnpm
bun: 1.3.14 - /Users/leoli/.bun/bin/bun

Reproduced against workers-sdk commit:
99eb50c

Please provide a link to a minimal reproduction

teamleaderleo#55

Describe the Bug

Miniflare.dispose() currently awaits browser cleanup and ProxyClient.dispose() before it calls Runtime.dispose().

As a result, Runtime.dispose() is reached only after those earlier cleanup awaits fulfill.

If either remains pending, runtime disposal is delayed for as long as that cleanup remains pending, leaving the workerd child running. If either rejects, execution can leave the cleanup sequence before Runtime.dispose() is called at all.

Reproduction

I reproduced this with a Miniflare instance and workerd child by holding ProxyClient.dispose() pending for one second.

Current behavior:

[fieldwork-456] before-release {
  "observedForMs": 1002,
  "workerdPid": 85892,
  "killRequested": false,
  "childStillAlive": true,
  "disposeSettled": false
}

After releasing proxy cleanup, execution reaches runtime disposal and the child exits with SIGKILL:

[fieldwork-456] after-release {
  "workerdPid": 85892,
  "exitCode": null,
  "signalCode": "SIGKILL",
  "disposeSettled": true
}

Expected behavior

Independent browser/proxy cleanup shouldn't control whether Miniflare requests termination of the workerd process it owns.

Runtime.dispose() already requests SIGKILL synchronously and returns the child-exit promise, so runtime disposal can be started before awaiting independent cleanup.

The outer Miniflare.dispose() can remain pending until the other cleanup completes.

Direction

I tested starting runtime disposal before the independent cleanup awaits, retaining the returned exit promise, and awaiting it before Miniflare.dispose() settles.

Under the same one-second blocked proxy cleanup:

[fieldwork-456] before-release {
  "observedForMs": 1001,
  "workerdPid": 86121,
  "killRequested": true,
  "childStillAlive": false,
  "disposeSettled": false
}

So workerd has already terminated, while Miniflare correctly continues waiting for the remaining cleanup.

A draft implementation and regression tests following this direction are here:

teamleaderleo#55

There is an additional question of whether every later teardown owner should be attempted after an independent cleanup failure, but the scope of this report is limited to ensuring that an earlier independent cleanup operation won't delay or skip owned runtime termination.

Please provide any relevant error logs

There isn't an error log associated with the pending-cleanup reproduction. The relevant observed process state is:

Current behavior:
[fieldwork-456] before-release {
  "observedForMs": 1002,
  "workerdPid": 85892,
  "killRequested": false,
  "childStillAlive": true,
  "disposeSettled": false
}

After releasing proxy cleanup:
[fieldwork-456] after-release {
  "workerdPid": 85892,
  "exitCode": null,
  "signalCode": "SIGKILL",
  "disposeSettled": true
}

Candidate behavior under the same one-second hold:
[fieldwork-456] before-release {
  "observedForMs": 1001,
  "workerdPid": 86121,
  "killRequested": true,
  "childStillAlive": false,
  "disposeSettled": false
}

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15085

Summary

Miniflare.dispose() awaits browser and ProxyClient.dispose() cleanup before calling Runtime.dispose(), so a pending or rejecting proxy/browser cleanup can delay or entirely skip termination of the workerd child process.

Classification

• Type: Bug
• Component: packages/miniflare
• Severity: Medium
• Has Reproduction: Yes (with link) — [miniflare] Start runtime disposal before browser/proxy cleanup teamleaderleo/workers-sdk#55
• Quality: Complete

Findings

• Created: not available in fetched data
• Author: teamleaderleo (Leo)
• Version: Reproduced against workers-sdk commit 99eb50ce1d3420a50ae0e95958bf49d65874706e (Node 22.23.1, pnpm 10.33.0, macOS 26.5.1, arm64)
• Labels: not available in fetched data
• Comments: not available in fetched data

Analysis

• Clear component identification: the bug is entirely within Miniflare's disposal sequence (Miniflare.dispose() → browser cleanup → ProxyClient.dispose() → Runtime.dispose()), so it maps to packages/miniflare.
• The report is high quality and complete: it includes full environment/version info, a specific reproduction commit, a linked minimal reproduction (a PR on the author's fork), instrumented before/after logs showing the workerd child (workerdPid 85892) staying alive while disposeSettled is false, and a precise statement of expected behavior.
• Root-cause hypothesis is well-articulated: independent browser/proxy cleanup is ordered ahead of runtime disposal, so (a) a pending cleanup delays Runtime.dispose() and (b) a rejecting cleanup can short-circuit the sequence before Runtime.dispose() is ever reached, leaking the workerd process.
• Severity is Medium rather than High: it requires a stalled/rejecting proxy or browser cleanup to trigger, but the failure mode (orphaned workerd child processes) is a real resource leak that could accumulate in long-running or test scenarios.
• Suggested fix direction: ensure Runtime.dispose() is not gated on the browser/ProxyClient cleanup promises — e.g. run runtime termination unconditionally (in a finally) or dispatch it independently of the other cleanup awaits.
• Note: the repository source tree and the issue's label/comment/date/state metadata were not available in this triage environment, so this assessment is based solely on the issue body. A maintainer should verify the current disposal ordering in packages/miniflare before implementing.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-documented, reproducible bug in Miniflare's disposal ordering with a plausible root cause and a linked reproduction. It describes a genuine resource-leak failure mode (orphaned workerd child) and warrants a fix rather than closure.

Action: A maintainer should verify the current dispose() ordering in packages/miniflare against the described sequence, confirm the reproduction, and re-order or decouple Runtime.dispose() so it is not gated on browser/ProxyClient cleanup. Triage the issue with the appropriate Miniflare package label.

Suggested Labels: none applied — label set for this repo was not available in the fetched data; a maintainer should apply the appropriate Miniflare package label.

Suggested Comment

Thanks for the detailed report and reproduction — this is really clear. The ordering issue you describe (running browser/ProxyClient cleanup before Runtime.dispose(), so a pending or rejecting cleanup can delay or skip runtime termination and leak the workerd child) makes sense. We'll take a look at decoupling runtime disposal from the earlier cleanup steps so termination is requested regardless of their state. If you'd like to open a PR against packages/miniflare with the fix from your reproduction, we'd be happy to review it.

Structured summary (JSON)

{
  "issueNumber": 15085,
  "title": "Miniflare.dispose() delays or skips Runtime.dispose() when browser/ProxyClient cleanup is pending or rejects, leaking the workerd child",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15085",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Well-documented, reproducible Miniflare disposal-ordering bug where runtime termination is gated on browser/ProxyClient cleanup, leaking the workerd child. It is a legitimate bug that warrants a fix rather than closure.",
  "suggestedAction": "Verify the current dispose() ordering in packages/miniflare, confirm the reproduction, and decouple Runtime.dispose() so it runs regardless of browser/ProxyClient cleanup state.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[dario-piotrowicz]

Hi @teamleaderleo thanks for the very detailed issue and the minimal reproduction, all of this is really helpful 🙏

Your draft PR looks pretty good to me, would you like to get that to a reviewable state and have it reviewed? or was that for showing a potential solution and you'd like us to create a new PR?

[teamleaderleo]

I can clean up my draft PR for review! I had opened the issue first to see if the direction seemed reasonable.