fix(server): survive client resets on WebSocket upgrade sockets

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

[Sipixer]

What Changed

Attach a no-op 'error' listener to every WebSocket upgrade socket, so a client reset degrades to an ordinary disconnect instead of killing the server process.

Only the Node factory in server.ts is touched. The Bun path goes through Bun.serve and never hands out raw upgrade sockets, so it needs no guard.

Why

A client that sends an upgrade request to /ws and then resets the connection takes the whole server down. Node throws an uncaught exception when a socket emits 'error' with no listener, and @effect/platform-node@4.0.0-beta.78 wires a 'close' listener on the raw upgrade socket in makeUpgradeHandler but never an 'error' one:

socket.on("close",()=>{if(!socket.writableEnded){fiber.interruptUnsafe(parent.id,ClientAbort.annotation)}})

Authentication is not a barrier. The 'upgrade' event fires before the route runs, so a client whose credentials are rejected has already passed through the unguarded socket — a rejected connection that resets kills the server exactly like an accepted one.

node:events:497
throw er; // Unhandled 'error' event
Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20)
errno: -104, code: 'ECONNRESET', syscall: 'read'
systemd: t3code.service: Main process exited, code=exited, status=1/FAILURE

Every in-flight session dies with the process, not just the one whose socket reset.

Trigger conditions. Two have to hold together. Probed against an unpatched 0.0.29-nightly.20260725.899:

client behaviour after upgrade	outcome
reads the response, closes with FIN	survives
reads the response, resets	survives
leaves the response unread, closes with FIN	survives
leaves the response unread, resets	dies

Unread bytes in the receive buffer make the kernel emit RST instead of FIN, and that RST lands on the unlistened socket. The same probe against a bare connection, partial headers, a completed GET /, a POST /mcp and an SSE GET /mcp leaves the server up — only the upgrade path is affected.

Impact. Unlikely from ordinary traffic: browsers read their response and close cleanly, and a three-week journal on my deployment shows zero occurrences from normal client churn. The crashes I observed were self-inflicted by a scripted client that ignored the response. But it takes about ten lines and no credentials to trigger deliberately and repeatedly, so on any deployment listening beyond loopback it is an availability problem rather than a rare glitch.

Upstream. The gap is in @effect/platform-node and arguably belongs there too. A guard here is still worth having: three lines, holds regardless of what upstream does, and keeps server liveness independent of a transitive dependency's socket handling.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — n/a, no UI change
• I included a video for animation/interaction changes — n/a

---

Tests

apps/server/src/upgradeSocketGuard.test.ts covers that the listener is attached to every upgrade socket, and that ten consecutive resets leave the server answering requests with no uncaughtException.

• new tests pass; full apps/server suite green (1622 passed, 7 skipped)
• vp check reports 0 errors (remaining 11 warnings are pre-existing in apps/web)
• vpr typecheck failures are limited to scripts/lib/resolve-catalog.ts and reproduce on a clean checkout
• built with vp pack and re-ran the probe against dist/bin.mjs: 20 consecutive resets on the previously fatal case, server alive, nothing fatal logged

Negative control: with the guard removed, the same sequence produces UNCAUGHT: ECONNRESET and exit code 42.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 136a433d-1aec-433c-9901-b3aede7542f5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward defensive bug fix that prevents server crashes when clients reset WebSocket connections during handshake. The change follows an existing pattern in the codebase, is minimal in scope, and includes comprehensive tests.

^{You can customize Macroscope's approvability policy. Learn more.}

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing as already fixed by the shared HTTP error guard. Current main attaches an error listener to each raw upgrade socket and wires that guard into the Node server factory. It also covers response-write errors. The separate upgrade-only wrapper is no longer needed. Related work: #4470.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.