Miniflare#dispose() rejects with ERR_SERVER_NOT_RUNNING when called twice, skipping the rest of its cleanup

[LeSingh1]

What versions & operating system are you using?

miniflare 5.20260801.1-alpha (reproduced against main @ 6dbd192), Node v24.14.1, macOS 15.

Please provide a link to a minimal reproduction

Inline below — six lines, no config or account needed.

Describe the Bug

Calling Miniflare#dispose() a second time rejects with ERR_SERVER_NOT_RUNNING ("Server is not running.").

dispose() has no "already disposed" guard, so a second call re-runs the whole teardown sequence. Two of those steps close a Node HTTP server that the first call already closed, and both propagate the resulting error:

#stopLoopbackServer() (packages/miniflare/src/index.ts):

#stopLoopbackServer(): Promise<void> {
	return new Promise((resolve, reject) => {
		assert(this.#loopbackServer !== undefined);
		this.#loopbackServer.stop((err) => (err ? reject(err) : resolve()));
	});
}

InspectorProxyController#dispose() (.../inspector-proxy/inspector-proxy-controller.ts):

server.closeAllConnections();
return new Promise((resolve, reject) => {
	server.close((err) => (err ? reject(err) : resolve()));
});

server.close() calls back with ERR_SERVER_NOT_RUNNING when the server was not listening. Because the rejection escapes dispose() mid-way, every cleanup step after the failing one is skipped. await this.#stopLoopbackServer() sits early in the finally block, so a second dispose() abandons all of:

await this.#stopLoopbackServer();          // ← rejects here
this.#webSocketServer.close();
removeDir(this.#tmpPath, { fireAndForget: true });
// ... email session dirs ...
await this.#maybeInspectorProxyController?.dispose();   // ← would reject here too
await this.#devRegistry.dispose();                       // unregister + stop file watcher
await this.#hyperdriveProxyController.dispose();
maybeInstanceRegistry?.delete(this);

So the dev registry file watcher and its registration files, the Hyperdrive proxy servers, and the instance registry entry are all left behind — which is the opposite of what a caller retrying dispose() is trying to achieve.

This is already being worked around inside this repo. packages/miniflare/test/test-shared/miniflare.ts string-matches the message to keep test teardown green:

} catch (e) {
	lastError = e;
	// Treat "already disposed" as success (idempotent disposal)
	const message = (e as Error).message;
	if (message === "Server is not running.") {
		return;
	}

Steps to reproduce

import { Miniflare } from "miniflare";

const mf = new Miniflare({ script: "", modules: true });
await mf.ready;
await mf.dispose();
await mf.dispose(); // ← rejects

Actual

Error [ERR_SERVER_NOT_RUNNING]: Server is not running.
    at Server.close (node:net:2367:12)
    at Object.onceWrapper (node:events:622:28)
    at Server.emit (node:events:508:28)
    at emitCloseNT (node:net:2427:8)
    at processTicksAndRejections (node:internal/process/task_queues:89:21)

The same happens with an inspector proxy running (inspectorPort: 0 + unsafeInspectorProxy: true) — and there the inspector proxy server is a second independent source of the same rejection, so fixing only the loopback server still leaves that path broken.

Expected

dispose() is idempotent: a second call resolves and the remaining cleanup still runs. Closing an already-closed server is not a failure to close it.

Please provide any relevant error logs

See the stack above. The failure is silent about what it skipped — the leftover dev registry watcher just keeps the Node event loop alive.

[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: #15097

Summary

Miniflare#dispose() is not idempotent: a second call rejects with ERR_SERVER_NOT_RUNNING and aborts the rest of the teardown, leaking the dev registry file watcher, Hyperdrive proxy servers, and the instance registry entry.

Classification

• Type: Bug
• Component: packages/miniflare
• Severity: Medium
• Has Reproduction: Yes (inline six-line script)
• Quality: Complete

Findings

• Created: 2026-08-09
• Author: LeSingh1
• Version: miniflare 5.20260801.1-alpha (also reproduced against main @ 6dbd192), Node v24.14.1, macOS 15
• Labels: package:miniflare
• Comments: 2

Analysis

• The issue is already closed. A maintainer (edmundhung, MEMBER) commented on 2026-08-10 stating: "We don't expect callers to call dispose() more than once... I'm going to close this as not planned." Per triage Step 2b (a maintainer indicated it should be closed), this maps to a CLOSE recommendation.
• Clearly a Miniflare (packages/miniflare) issue: the reporter names packages/miniflare/src/index.ts (#stopLoopbackServer()) and the inspector-proxy controller as the two independent sources of the rejection.
• Root cause is well diagnosed: dispose() has no "already disposed" guard, so a second call re-runs teardown; server.close() calls back with ERR_SERVER_NOT_RUNNING for an already-closed server, and because the rejection escapes mid-finally, subsequent cleanup steps (dev registry watcher, Hyperdrive proxies, instance registry entry) are skipped and leak.
• High-quality report on its own merits — minimal inline reproduction, actual vs. expected behavior, full stack trace, and version/OS info. However, the maintainer's stated position is that calling dispose() twice is not a supported usage pattern, and that any real halfway-through cleanup failure should be fixed with a genuine reproduction rather than by making double-disposal idempotent.

Recommendation

Status: CLOSE

Reasoning: A maintainer (edmundhung) has already decided to close this as not planned, on the grounds that calling dispose() more than once is not an expected usage pattern. The issue is already in a closed state, so this recommendation confirms the maintainer's decision.

Action: No further action required — the issue is already closed as not planned. If a genuine halfway-through cleanup failure surfaces during normal (single) disposal, a new issue with a real reproduction should be opened.

Suggested Labels: package:miniflare

Suggested Comment

Thanks for the detailed report. As noted, we don't expect callers to invoke dispose() more than once, so making double-disposal idempotent isn't something we plan to do. If cleanup can fail partway through during a normal single dispose() and leave resources running, that's a real bug we'd want to fix — please open a new issue with a reproduction that doesn't rely on calling dispose() twice, and we'll investigate. Closing this as not planned for now.

Structured summary (JSON)

{
  "issueNumber": 15097,
  "title": "Miniflare#dispose() rejects with ERR_SERVER_NOT_RUNNING when called twice, skipping the rest of its cleanup",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15097",
  "recommendation": "CLOSE",
  "difficulty": "n/a",
  "reasoning": "A maintainer (edmundhung) has already decided to close this as not planned, since calling dispose() more than once is not an expected usage pattern. The issue is already in a closed state.",
  "suggestedAction": "No further action required; the issue is already closed as not planned. If a genuine halfway-through cleanup failure occurs during a normal single dispose(), open a new issue with a real reproduction.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["package:miniflare"]
}

[edmundhung]

Thanks for reporting this. We don't expect callers to call dispose() more than once or catch an error and retry it. If cleanup can fail halfway through and leave resources running, that should be fixed inside dispose() with a real reproduction.

I'm going to close this as not planned.