[miniflare] dispatchFetch JSON-parses gzip-encoded ERROR_STACK 500 bodies

[quantizor]

What versions & operating system are you using?

• macOS (darwin 25.6.0), arm64
• Node v24.11.0
• miniflare 4.20260701.0 (via wrangler 4.107.0 / @cloudflare/vite-plugin 1.43.0)
• undici 7.28.0 (miniflare's copy)

On current main, Miniflare#dispatchFetch still JSON-parses the ERROR_STACK body (JSON.parse(await response.text()) after #14766). That parse still fails if the body is gzip.

Please provide a link to a minimal reproduction

cloudflare/vinext#2921

Describe the Bug

Miniflare#dispatchFetch treats a workerd 500 that carries MF-Experimental-Error-Stack as a structured exception and parses the body as JSON:

const stack = response.headers.get(CoreHeaders.ERROR_STACK);
if (response.status === 500 && stack !== null) {
  const caught = JsonErrorSchema.parse(await response.json());
  throw reviveError(this.#workerSrcOpts, caught);
}

(packages/miniflare/src/index.ts, dispatchFetch. #14766 switched this to response.text() + JSON.parse, which has the same failure when the bytes are gzip.)

DispatchFetchDispatcher does not decompress. It forwards the caller's headers, including Accept-Encoding: gzip. workerd then returns the JSON error with Content-Encoding: gzip. response.json() / JSON.parse(text) therefore sees gzip magic 1f 8b 08 and throws:

SyntaxError: Unexpected token '\u001f', "\u001f�\b..." is not valid JSON
    at JSON.parse
    at parseJSONFromBytes (undici)

The Content-Encoding strip that follows this branch never runs, so the gzip is not rewritten to MF-Content-Encoding first.

This is the same response.json() fragility as #8917 (empty HEAD body). Here the body is present but compressed.

How it shows up with @cloudflare/vite-plugin: handleWebSocket copies every upgrade header via createHeaders (including the browser's Accept-Encoding: gzip) and await miniflare.dispatchFetch(...). When the Worker throws on a WebSocket upgrade, this gzip parse rejects. On vite-plugin 1.43.0 that rejection is unhandled and kills the Node process. On current main, #14862 catches it and socket.destroy()s, so the process lives but the Worker's exception is never revived or logged. Related: #15170 (non-101 upgrade responses are destroyed).

Expected: decompress (or ignore Accept-Encoding) before parsing the ERROR_STACK body, then reviveError the Worker exception.

Workaround on the vinext side: absorb this gzip SyntaxError in the process-level socket-error backstop: cloudflare/vinext#2922

Please provide any relevant error logs

SyntaxError: Unexpected token '\u001f', "\u001f�\b..." is not valid JSON
    at JSON.parse (<anonymous>)
    at parseJSONFromBytes (undici/lib/web/infra/index.js)
    at successSteps (undici/lib/web/fetch/body.js)
    at Miniflare.dispatchFetch (miniflare/dist/src/index.js)
    at Server.<anonymous> (@cloudflare/vite-plugin/dist/index.mjs) // handleWebSocket upgrade

Instrumented Response.json() on the failing call:

• status 500
• content-type: application/json
• content-encoding: gzip
• body starts 1f8b0800000000000013 (gzip magic)
• MF-Content-Encoding is unset (the strip after the ERROR_STACK branch did not run)

[quantizor]

Sibling: the @cloudflare/vite-plugin upgrade handler that forwards Accept-Encoding: gzip into this dispatchFetch is #15199.

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

Summary

Miniflare#dispatchFetch fails to parse a workerd 500 error response carrying MF-Experimental-Error-Stack when the body is gzip-compressed, throwing a SyntaxError from JSON.parse instead of reviving and rethrowing the Worker's exception.

Classification

• Type: Bug
• Component: packages/miniflare
• Severity: Medium
• Has Reproduction: Yes (Dev server exits on gzipped Worker 500 during WebSocket upgrade (socket-error-backstop rethrows undici JSON parse) vinext#2921; also independently reproduced by auto-triage)
• Quality: Complete

Findings

• Created: 2026-08-15
• Author: quantizor (Evan Jacobs)
• Version: miniflare 4.20260701.0 (via wrangler 4.107.0 / @cloudflare/vite-plugin 1.43.0), undici 7.28.0, Node v24.11.0, macOS (darwin 25.6.0) arm64 — reported against current main
• Labels: none
• Comments: 4

Analysis

• Precisely diagnosed Miniflare bug in packages/miniflare/src/index.ts dispatchFetch. The 500-with-ERROR_STACK branch parses the body via JSON.parse(await response.text()) (introduced by PR [miniflare] Report the Worker's error for HEAD requests #14766). DispatchFetchDispatcher forwards the caller's Accept-Encoding: gzip and does not decompress, so workerd returns a gzip body; the Content-Encoding → MF-Content-Encoding rewrite only happens after the failing parse branch, so JSON.parse chokes on the gzip magic bytes (1f 8b 08).
• Same class of fragility as wrangler dev throws an internal error when reporting a worker error for a HEAD request #8917 (empty HEAD body), now surfacing with a compressed body rather than an empty one.
• Reproducibility is strong: a minimal reproduction link is provided, and the auto-triage bot confirmed "✅ Successfully reproduced" (comment 3) — the error only occurs when Accept-Encoding: gzip is forwarded.
• A fix is already in flight. The reporter posted PR [miniflare] Revive gzipped ERROR_STACK bodies in dispatchFetch #15200 (with companion header fix PR [vite-plugin] Drop Accept-Encoding on Worker WebSocket upgrades #15201) in comment 4. These are not yet merged/released, so this is not "already fixed in a prior release" — the issue should stay open to track the PRs to completion.
• Related/sibling references: [vite-plugin] WebSocket upgrade forwards Accept-Encoding gzip; Worker throw becomes undici JSON.parse crash #15199 (vite-plugin upgrade handler forwarding Accept-Encoding: gzip), [vite-plugin] Non-101 WebSocket upgrade responses are destroyed instead of delivered to the client in dev #15170 (non-101 upgrade responses destroyed), [vite-plugin] Fix flaky WebSocket upgrade test and harden upgrade handler #14862 (rejection caught + socket.destroy() on main).

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-documented, independently reproduced Miniflare defect against current main, with a clearly identified root cause and code location. Fix PRs (#15200, #15201) are already open but not yet merged/released, so the issue should remain open to track them to completion and closure.

Action: Review and land PR #15200 (and companion #15201). Ensure a regression test covers a gzip-encoded 500 ERROR_STACK response (decompress or perform the Content-Encoding → MF-Content-Encoding rewrite before parsing). Close the issue once the fix ships.

Suggested Labels: none (repository label list is unavailable in the pre-fetched data; omitting rather than guessing)

Suggested Comment

Thanks for the detailed root-cause analysis and for opening a fix — this is very helpful. You've correctly identified that the ERROR_STACK branch in dispatchFetch parses the body before the Content-Encoding → MF-Content-Encoding rewrite runs, so a gzip-compressed workerd 500 blows up in JSON.parse. We'll review #15200 (and companion #15201) and get this landed. Keeping this open to track the fix through to release.

Structured summary (JSON)

{
  "issueNumber": 15198,
  "title": "[miniflare] dispatchFetch JSON-parses gzip-encoded ERROR_STACK 500 bodies",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15198",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Well-documented, independently reproduced Miniflare bug against current main: the dispatchFetch ERROR_STACK branch parses the response body as JSON before the Content-Encoding rewrite runs, so a gzip-compressed 500 throws a SyntaxError. Fix PRs #15200 and #15201 are already open but not yet merged.",
  "suggestedAction": "Review and land PR #15200 (and companion #15201), ensure a regression test covers a gzip-encoded 500 ERROR_STACK response, and close the issue once the fix ships.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ✅ Successfully reproduced. dispatchFetch with Accept-Encoding: gzip on a 500 ERROR_STACK response JSON-parses gzip bytes and throws SyntaxError: Unexpected token '\u001f'... instead of reviving the Worker error. Works correctly without the header.

[quantizor]

Fix: #15200 (companion header fix: #15201).