starred/vinext

Fork 0

mirror of https://github.com/cloudflare/vinext.git synced 2026-05-09 08:25:34 +02:00

[GH-ISSUE #905] Dev server crashes with Unhandled 'error' event (ECONNRESET) when editing files #200

New issue

Closed

opened 2026-05-06 12:38:06 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-06 12:38:06 +02:00

Owner

Originally created by @eashish93 on GitHub (Apr 25, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/905

What happens

Dev server (bun dev) crashes intermittently while editing source files.
The crash is always an Unhandled 'error' event on a Socket with code
ECONNRESET, originating from Node internals only — no vinext or app
code in the stack:

Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
Emitted 'error' event on Socket instance at:
at Socket.onerror (node:internal/streams/readable:1031:14)
at Socket.emit (node:events:508:28)
...
errno: -54, code: 'ECONNRESET', syscall: 'read'

When

Reliably while saving files in the editor, especially when the browser
is mid-request (e.g. RSC stream still flushing) and HMR triggers a
reload. The hint is that two requests just completed (compile: ...,
render: ...), then the next save kills the process.

Why it's a bug

ECONNRESET on a peer-closed socket is normal. It shouldn't crash the
process. Node defaults to throw on unhandled error events, so the
underlying server (HTTP/WS) needs to attach a no-op error handler,
or vinext should attach one at the layer where it owns the socket.

For comparison, Vite handles this in vite's HMR server, and Next.js
ships an 'error' handler on req.socket for the same reason.

Env

vinext:
Node: v25.2.1
Bun: <bun --version>
OS: macOS (darwin 25.3.0)

Repro

bun dev
Open the app in browser, navigate around
Edit a source file rapidly (or save mid-navigation)
Server crashes within ~10 saves with the trace above

Originally created by @eashish93 on GitHub (Apr 25, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/905 ## What happens Dev server (`bun dev`) crashes intermittently while editing source files. The crash is always an `Unhandled 'error' event` on a Socket with code `ECONNRESET`, originating from Node internals only — no vinext or app code in the stack: Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:216:20) Emitted 'error' event on Socket instance at: at Socket.onerror (node:internal/streams/readable:1031:14) at Socket.emit (node:events:508:28) ... errno: -54, code: 'ECONNRESET', syscall: 'read' ## When Reliably while saving files in the editor, especially when the browser is mid-request (e.g. RSC stream still flushing) and HMR triggers a reload. The hint is that two requests just completed (`compile: ...`, `render: ...`), then the next save kills the process. ## Why it's a bug ECONNRESET on a peer-closed socket is normal. It shouldn't crash the process. Node defaults to `throw` on unhandled `error` events, so the underlying server (HTTP/WS) needs to attach a no-op error handler, or vinext should attach one at the layer where it owns the socket. For comparison, Vite handles this in vite's HMR server, and Next.js ships an `'error'` handler on `req.socket` for the same reason. ## Env - vinext: <fill in version from package.json> - Node: v25.2.1 - Bun: <bun --version> - OS: macOS (darwin 25.3.0) ## Repro 1. `bun dev` 2. Open the app in browser, navigate around 3. Edit a source file rapidly (or save mid-navigation) 4. Server crashes within ~10 saves with the trace above

BreizhHardware closed this issue

2026-05-06 12:38:06 +02:00

BreizhHardware commented

2026-05-06 12:38:07 +02:00

Author

Owner

@james-elicx commented on GitHub (Apr 26, 2026):

I wasn't actually able to reproduce this in my local projects, but I had Claude scout through Next.js and figure out if they did anything that might help with HMR. Just merged a PR to no-op the socket errors which should help here.

@james-elicx commented on GitHub (Apr 26, 2026): I wasn't actually able to reproduce this in my local projects, but I had Claude scout through Next.js and figure out if they did anything that might help with HMR. Just merged a PR to no-op the socket errors which should help here.

BreizhHardware commented

2026-05-06 12:38:08 +02:00

Author

Owner

@james-elicx commented on GitHub (Apr 26, 2026):

Hmph, I managed to get a crash to occur locally after that fix... Trying another more aggressive one...

@james-elicx commented on GitHub (Apr 26, 2026): Hmph, I managed to get a crash to occur locally after that fix... Trying another more aggressive one...

BreizhHardware commented

2026-05-06 12:38:08 +02:00

Author

Owner

@james-elicx commented on GitHub (Apr 26, 2026):

argh. i no longer run into the crash in the original way i was able to reproduce it, but i've started running into it during navigating around the project i'm testing in...

@james-elicx commented on GitHub (Apr 26, 2026): argh. i no longer run into the crash in the original way i was able to reproduce it, but i've started running into it during navigating around the project i'm testing in...

BreizhHardware commented

2026-05-06 12:38:08 +02:00

Author

Owner

@james-elicx commented on GitHub (Apr 26, 2026):

Alright. Think I finally got an actual fix.

Will do a release for it in the morning, but you can try a prerelease for the pr if you want to.

There will be a debug env var VINEXT_DEBUG_SOCKET_ERRORS=1 that you can use to log debug info for the flag as well which will log that it was initialised, and will log when it swallows the errors.

My second reproduction scenario was spamming around hundreds of different prefetched routes really fast and refreshing at the same time.

Managed to get it to log [vinext] absorbed uncaughtException ECONNRESET when trying to repro, which means the patch is now working as intended.

@james-elicx commented on GitHub (Apr 26, 2026): Alright. Think I finally got an actual fix. Will do a release for it in the morning, but you can try a prerelease for the pr if you want to. There will be a debug env var `VINEXT_DEBUG_SOCKET_ERRORS=1` that you can use to log debug info for the flag as well which will log that it was initialised, and will log when it swallows the errors. My second reproduction scenario was spamming around hundreds of different prefetched routes really fast and refreshing at the same time. Managed to get it to log `[vinext] absorbed uncaughtException ECONNRESET` when trying to repro, which means the patch is now working as intended.

BreizhHardware referenced this issue

2026-05-06 12:39:44 +02:00

[PR #262] [CLOSED] feat(font): replace generated font catalog with Vite import-rewriting transform #425

BreizhHardware referenced this issue

2026-05-06 13:09:55 +02:00

[PR #656] [MERGED] feat(font): replace generated google font catalog with virtual import rewrites #748