vite-plugin: server.restart() wedges permanently when an HTTP request straddles the Miniflare options swap (bundled-dev/rolldown pipeline)

[zhorton34]

Which Cloudflare product(s) does this pertain to?

@cloudflare/vite-plugin

Versions

@cloudflare/vite-plugin 1.52.1 (latest at time of filing), wrangler 4.123.0, @cloudflare/workers-types 5.20260816.1, vite-plus 0.2.5 (Vite 8.1.5 core), node 24.x, darwin-arm64 (also reproduces on GitHub Actions macos-14)

Describe the bug

When server.restart() runs while an HTTP request is in flight to the dev server, the restart can wedge permanently: the plugin's module-scope shared context reuses the live Miniflare instance, setOptions completes ("Miniflare is ready", module runners re-initialize), but the next step — getCurrentWorkerNameToExportTypesMap → fetchWorkerExportTypes → miniflare.dispatchFetch(GET_EXPORT_TYPES_PATH, …) (dist/index.mjs:66627-66630, called from devPlugin.configureServer at :83080) — never resolves. configureServer never returns → _createServer never returns → server.restart() never settles. The old server's close() is never reached (verified by instrumentation), so the stale workerd lives on indefinitely.

Traffic during the restart is both necessary and sufficient (2×2 differential, 9/9 reproduction with traffic, 14/14 clean without):

• restart with a concurrent curl poll loop → hangs 3/3 (fresh app, no D1 activity at all)
• identical restart with no in-flight traffic → completes 3/3 (plus 11/11 across earlier trials)

OS-level signature at hang time, consistent across 7/7 hangs:

• lsof on workerd shows exactly one entry-socket connection in CLOSE_WAIT whose peer no longer exists (the aborted straddling request) — never present in non-hang runs
• workerd sample shows in-flight JsRpcTarget frames (a straddling request holding a multi-roundtrip module-runner RPC across the swap); workerd does not cancel a request on client disconnect
• node side logs Internal server error: fetch failed from Miniflare.dispatchFetch via undici at restart time
• plugin debuglog's last line ever: Fetching export types for worker "…" — the watchdog we added fires 30s later, every time

Reproduction and an honest scoping caveat

A plain-Vite worker scaffold at the same pins did NOT reproduce the permanent wedge in 8 escalating-fidelity trials (including a real options swap via config-triggered restart, a D1 binding, a 40-module chain, and tight polling — the mid-swap fetch failed abort signature reproduces, but export-types still resolves in ~3s). The permanent wedge reproduces only with Vite's bundled-dev/rolldown pipeline active (the wedged node process runs rolldown worker threads). Your 1.48.0 changelog notes recent work on exactly this codepath ("compatibility with Vite's experimental.bundledDev option, keeping Miniflare and related resources alive during mid-serve builds") — the interaction of that keep-alive behavior with an in-flight request across setOptions looks like the fault line.

Deterministic repro available: a Pioneer framework scaffold (pioneer new from github.com/find-how/pioneer.find.how, which runs the cloudflare plugin under the bundled-dev pipeline) + a curl poll loop + a config-triggered restart reproduces 9/9. Happy to provide the trial harness and captured sample/lsof evidence.

Nearest existing issues checked (not duplicates): #11171 (Bun-specific restart hang), withastro/astro#17492 (dispatchFetch POST hang).

Impact / downstream mitigation

Any framework or tooling that restarts the dev server while a client is polling (health checks, test harnesses, HMR-adjacent tooling) can permanently wedge the dev session with no error surfaced. We now mitigate downstream by gating incoming requests with a 503 during restart, which eliminates the trigger — but the underlying non-settling dispatchFetch and never-closed old server remain upstream behavior. A cancellation/timeout on the export-types fetch, or draining/aborting in-flight requests before setOptions, would fix the class.

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

Summary

server.restart() in @cloudflare/vite-plugin wedges permanently when an HTTP request is in flight across the Miniflare options swap under Vite's bundled-dev/rolldown pipeline — fetchWorkerExportTypes → miniflare.dispatchFetch never resolves, so configureServer and the restart never settle and the old workerd is never closed.

Classification

• Type: Bug
• Component: packages/vite-plugin-cloudflare (with a likely secondary Miniflare/workerd interaction)
• Severity: High
• Has Reproduction: Yes (deterministic repro described: Pioneer scaffold pioneer new from github.com/find-how/pioneer.find.how + curl poll loop + config-triggered restart, 9/9; no clonable minimal repo attached but a repro recipe + OS-level evidence provided)
• Quality: Complete

Findings

• Created: 2026-08-17
• Author: zhorton34
• Version: @cloudflare/vite-plugin 1.52.1, wrangler 4.123.0, @cloudflare/workers-types 5.20260816.1, vite-plus 0.2.5 (Vite 8.1.5 core), node 24.x, darwin-arm64 (also GitHub Actions macos-14)
• Labels: none
• Comments: 0

Analysis

• Component: Clearly @cloudflare/vite-plugin. The reporter cites the exact codepath: getCurrentWorkerNameToExportTypesMap → fetchWorkerExportTypes → miniflare.dispatchFetch(GET_EXPORT_TYPES_PATH, …) (dist/index.mjs:66627-66630, called from devPlugin.configureServer). The non-settling dispatchFetch and workerd not cancelling requests on client disconnect suggest a secondary Miniflare/workerd interaction.
• Reproducibility: Strong. A controlled 2×2 differential (traffic during restart hangs 9/9; no in-flight traffic completes 14/14) plus a deterministic repro recipe and OS-level signatures (single CLOSE_WAIT entry socket on workerd, in-flight JsRpcTarget frames, Internal server error: fetch failed from dispatchFetch). The reporter honestly scoped it: plain-Vite did NOT wedge across 8 trials; the permanent wedge requires the bundled-dev/rolldown pipeline.
• Severity: High — any tooling that restarts the dev server while a client is polling (health checks, test harnesses, HMR-adjacent tooling) can permanently wedge the dev session with no error surfaced. Not data loss, but a hard hang with no user-visible cause. A downstream mitigation exists (gating incoming requests with 503 during restart), which lowers urgency but does not fix the upstream class.
• Root-cause hypothesis / fix direction (from reporter): The interaction of the experimental.bundledDev keep-alive behavior (referenced in the 1.48.0 changelog — keeping Miniflare alive during mid-serve builds) with an in-flight request across setOptions. Suggested fixes: a cancellation/timeout on the export-types fetch, or draining/aborting in-flight requests before setOptions.
• Duplicate check: Reporter explicitly checked nearest issues and states they are NOT duplicates — [Bun] HMR infinite hang in @cloudflare/vite-plugin due to Miniflare's ws.once('upgrade') dependency #11171 (Bun-specific restart hang) and @astrojs/cloudflare dev: outbound POST from server code (Actions) never completes — GET works, plain @cloudflare/vite-plugin works withastro/astro#17492 (dispatchFetch POST hang). No maintainer or reporter has flagged this as a duplicate.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-scoped, reproducible bug in @cloudflare/vite-plugin with a plausible root cause and concrete fix directions. It is not spam, stale, a duplicate, user error, or out of repo scope, and it has enough information to act on.

Action: Route to the vite-plugin maintainers to verify the hang against the bundled-dev/rolldown pipeline and evaluate adding a timeout/cancellation to the export-types dispatchFetch and/or draining/aborting in-flight requests before setOptions. Confirm whether the non-cancelling dispatchFetch needs a Miniflare-side change. Consider requesting the reporter's offered trial harness and captured sample/lsof evidence, or a minimal clonable repro, to speed verification.

Suggested Labels: package:vite-plugin, bug

Suggested Comment

Thanks for the exceptionally detailed report — the 2×2 differential, the codepath pointers, and the lsof/sample evidence are really helpful. This looks like a real hang in the export-types dispatchFetch when an in-flight request straddles the Miniflare options swap under the bundled-dev/rolldown pipeline.

To help us verify quickly, could you share the trial harness and the captured sample/lsof output you mentioned, and if possible a minimal repo we can clone and run? In particular it would help to confirm:

• Whether the hang still reproduces on the latest @cloudflare/vite-plugin
• Whether it reproduces without the Pioneer scaffold (a bare Vite experimental.bundledDev setup + poll loop + config-triggered restart)

We'll dig into adding a timeout/cancellation on the export-types fetch and/or draining in-flight requests before setOptions.

Structured summary (JSON)

{
  "issueNumber": 15241,
  "title": "vite-plugin: server.restart() wedges permanently when an HTTP request straddles the Miniflare options swap (bundled-dev/rolldown pipeline)",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15241",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Well-scoped, reproducible bug in @cloudflare/vite-plugin where the export-types dispatchFetch never resolves when an in-flight request straddles the Miniflare options swap under the bundled-dev/rolldown pipeline. High-quality report with root-cause analysis and concrete fix directions.",
  "suggestedAction": "Route to vite-plugin maintainers to verify the hang and evaluate a timeout/cancellation on the export-types fetch and/or draining in-flight requests before setOptions; optionally request the reporter's harness/evidence or a minimal clonable repro.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["package:vite-plugin", "bug"]
}