fix(dev): absorb gzip JSON parse in socket-error backstop

[quantizor]

Summary

• absorb the JSON.parse SyntaxError that miniflare's dispatchFetch throws on a gzip-encoded workerd 500 during a Worker WebSocket upgrade
• keep the match narrow: gzip magic as the unexpected token plus is not valid JSON; HTML bodies, empty bodies, and other parse failures still crash
• skip the absorb during prerender so vinext build still fails on a gzip parse

Closes #2921

The vite-plugin upgrade handler awaits dispatchFetch with no try/catch. When workerd returns a 500 JSON error with Content-Encoding: gzip (the plugin forwards the browser's Accept-Encoding), miniflare's custom dispatcher does not decompress before response.json(). The resulting SyntaxError becomes an unhandled rejection, the socket-error backstop rethrows it, and the dev server exits.

This is the vinext-side absorb, following #1846. The durable fixes remain in miniflare (decompress before response.json()) and @cloudflare/vite-plugin (catch dispatchFetch on upgrade).

Validation

• pnpm exec vp check packages/vinext/src/server/socket-error-backstop.ts tests/socket-error-backstop.test.ts
• pnpm test tests/socket-error-backstop.test.ts (12 passed)
• git diff --check
• listener smoke: gzip unhandledRejection keeps the process alive; a genuine Error still exits 7; VINEXT_PRERENDER=1 still crashes on gzip parse

[quantizor]

workers-sdk follow-ups:

• [miniflare] dispatchFetch JSON-parses gzip-encoded ERROR_STACK 500 bodies workers-sdk#15198 (miniflare)
• [vite-plugin] WebSocket upgrade forwards Accept-Encoding gzip; Worker throw becomes undici JSON.parse crash workers-sdk#15199 (vite-plugin)

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@vinext/cloudflare@2922

npm i https://pkg.pr.new/create-vinext-app@2922

npm i https://pkg.pr.new/@vinext/types@2922

npm i https://pkg.pr.new/vinext@2922

commit: c24ee6c

[github-actions]

Performance benchmarks

Compared c24ee6c against base 3ec5bdc using alternating same-runner rounds. Next.js was unchanged and skipped.

0 improved · 0 regressed · 6 within ±1.5%

Scenario	Framework	Baseline	Current	Change
Client bundle size (gzip)	vinext	135.4 KB	135.4 KB	⚫ 0.0%
Client entry size (gzip)	vinext	122.8 KB	122.8 KB	⚫ +0.0%
Dev server cold start	vinext	2.99 s	2.99 s	⚫ -0.1%
Production build time	vinext	3.21 s	3.19 s	⚫ -0.9%
RSC entry closure size (gzip)	vinext	114.8 KB	114.9 KB	⚫ +0.0%
Server bundle size (gzip)	vinext	195.2 KB	195.2 KB	⚫ +0.0%

View detailed results and traces

_{🟢 improvement · 🔴 regression · ⚫ change below 1.5% · paired base/head}

[james-elicx]

This feels like the wrong fix for the problem.

From what I understand, this will match anything containing is not valid JSON and \x1F, so it could potentially swallow unrelated errors.

I am also a bit concerned that this is going to blindly swallow the errors rather than recovering or surfacing failures.

Further, it looks like you've already identified better upstream fixes and have PRs for them.

To be honest, this PR looks like an agent doing whatever it can to silence a problem it ran into, rather than just focusing on the proper fix.

I'll close this for now. Please do let me know if you disagree with my assessment.

[quantizor]

@james-elicx sounds good, and you are correct.