Problem

nuxt dev can restart itself in a loop with:

 ERROR  [unhandledRejection] read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)

●  Restarting Nuxt due to error: Error: read ECONNRESET

A client hanging up mid-request is ordinary dev-server traffic — a browser reloading while a page is still streaming, a tab closed mid-navigation, a stale client from another project reconnecting to a port this server now owns. When such an error surfaces as an unhandled rejection, both places that watch for one treat it as fatal:

• createRestartHook schedules a hard restart;
• the forked dev process reports it over IPC and calls process.exit().

With a client that keeps reconnecting, this loops until the dev server is unusable — every reconnect kills the session that was just rebuilt.

Where the rejection comes from

I traced the origin in a real project by wrapping the candidate call sites and logging which one rejects. It is NodeDevWorker.handleUpgrade in nitro, which returns proxy.ws(...) without awaiting or catching it:

// nitropack/dist/core/index.mjs
handleUpgrade(req, socket, head) {
  if (!this.ready) { return }
  return this.#proxy.proxy.ws(req, socket, { target: this.#address, xfwd: true }, head)
}

When the Nitro dev worker is replaced, every proxied websocket dies and that promise rejects. Adding a .catch() there removed the rejections entirely (8 in 30s → 0) and the restarts with them, so the leak itself belongs in nitro and I am happy to open that separately.

This PR is the guard on the other side: whatever leaks it, a connection the peer dropped should not end the dev session.

Change

isBrokenPipe already encodes exactly this rule — "a property of the other end of the pipe, not a fault in the dev server". This adds a sibling predicate for aborted connections (ECONNRESET, ECONNABORTED, ERR_STREAM_PREMATURE_CLOSE) and applies it in both fatal paths.

The IPC handler also moves from once to on, so an ignored connection error no longer consumes the listener and leaves a later genuine rejection unreported.

Logging is deliberately untouched: the error still reaches the reporter, so the event stays visible in the terminal — it just no longer ends the session.

Tests

• errors.spec.ts — coverage for the new predicate.
• restart-hook.spec.ts — an ECONNRESET no longer triggers the restart callback, while an unrelated error still does.

pnpm lint, pnpm test:types and pnpm test:knip are clean. pnpm test:unit passes except for two pre-existing failures in test/e2e/commands.spec.ts (dev, works with dev server, both expecting 200 and getting 404) — I confirmed those fail identically on an unmodified main in my environment, so they are unrelated to this change.