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

@cloudflare/vite-plugin dev server can hang permanently on server.restart() when an HTTP request is in flight, because fetchWorkerExportTypes (miniflare.dispatchFetch(GET_EXPORT_TYPES_PATH)) never resolves, blocking configureServer and leaking a stale workerd.

Classification

• Type: Bug
• Component: packages/vite-plugin-cloudflare
• Severity: High
• Has Reproduction: Yes (detailed reproduction methodology and OS-level diagnostics; no clone-and-run repo link provided)
• Quality: Complete

Findings

• Created: not available in provided context (line truncated in context.json)
• Author: zhorton34 (Zak Horton) — not a bot
• 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), node 24.x, darwin-arm64 (also repros on GitHub Actions macos-14)
• Labels: not available in provided context (line truncated in context.json)
• Comments: not available in provided context (line truncated in context.json)

Analysis

• Component identification is unambiguous: the reporter explicitly selects @cloudflare/vite-plugin and cites specific offsets in the built plugin (dist/index.mjs:66627-66630, configureServer at :83080). This maps to packages/vite-plugin-cloudflare.
• Reproducibility is strong. The reporter ran a 2×2 differential — 9/9 hangs with concurrent traffic during restart, 14/14 clean completions without — isolating "in-flight traffic during restart" as both necessary and sufficient. No clone-and-run repo is attached, but the steps (restart under a concurrent curl poll loop) are precise and reproducible.
• Plausible root cause with evidence. OS-level signature is consistent across 7/7 hangs: a single entry-socket in CLOSE_WAIT with a vanished peer (the aborted straddling request), and workerd sample showing in-flight JsRpcTarget frames — consistent with workerd not cancelling a request on client disconnect, leaving a module-runner RPC pending across the instance swap. This blocks fetchWorkerExportTypes → configureServer → _createServer → server.restart().
• Severity is High: a permanently wedged dev server plus a leaked workerd process is a significant developer-experience failure, though it requires the specific timing of traffic straddling a restart (not all users hit it on every restart).
• Interaction with types fetch: the hang is in the wrangler types-adjacent export-types fetch path (GET_EXPORT_TYPES_PATH), suggesting a candidate fix area (timeout/abort the export-types dispatch, or drain/abort in-flight requests before/around setOptions).

Recommendation

Status: KEEP OPEN

Reasoning: This is a high-quality, reproducible bug report against the latest plugin version with a clear failure path and supporting diagnostics. It identifies a real robustness gap in the plugin's restart flow and warrants investigation by maintainers.

Action: Route to a packages/vite-plugin-cloudflare maintainer to verify the reproduction (restart under concurrent traffic) and evaluate guarding the export-types dispatch (e.g. abort/timeout the miniflare.dispatchFetch(GET_EXPORT_TYPES_PATH) call, or ensure in-flight requests are drained/aborted around the instance swap) so a stalled RPC cannot wedge configureServer.

Suggested Labels: (none applied — cannot confirm which labels exist from the provided context; a maintainer should apply the appropriate package:vite-plugin/bug labels)

Suggested Comment

Thanks for the exceptionally detailed report and the 2×2 differential — the "in-flight traffic during restart" isolation and the CLOSE_WAIT / JsRpcTarget diagnostics are really helpful. This does look like a real robustness gap in the plugin's restart flow, where the export-types dispatch (GET_EXPORT_TYPES_PATH) can block configureServer if an RPC straddles the instance swap. We'll take a look. If you happen to have a minimal clone-and-run repo (even just the app plus your curl poll loop), that would help us confirm the fix.

Structured summary (JSON)

{
  "issueNumber": 15241,
  "title": "@cloudflare/vite-plugin dev server hangs permanently on server.restart() with in-flight traffic",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15241",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "High-quality, reproducible bug against the latest plugin version: in-flight traffic during server.restart() leaves a module-runner RPC pending, so the export-types dispatch never resolves and wedges configureServer while leaking a stale workerd.",
  "suggestedAction": "Route to a packages/vite-plugin-cloudflare maintainer to verify the restart-under-traffic reproduction and guard the GET_EXPORT_TYPES_PATH dispatch (abort/timeout or drain in-flight requests around the instance swap).",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[edmundhung]

Thanks for digging into this! The Pioneer link currently returns a 404, so could you provide a minimal reproduction without Pioneer?

Ideally it would use Vite and the Cloudflare plugin directly, but Vite+ with the Cloudflare plugin would also work. Could you also confirm whether it still reproduces with version 1.53.0? Without that reduction, it's difficult to tell which integration is responsible.