[mcollina]

Problem

The legacy GET /mcp SSE stream writes every event (live sends, the Last-Event-ID replay, heartbeats) with raw.write() and ignores the return value. For a client that stops reading, every broadcast stays in Node's writable buffer until the socket dies. That is 25 MB for 400 notifications of 64 KB, per stalled stream.

Fix

• Live sends and heartbeats now go through a new writeSSE(). When write() reports back-pressure and more than 1 MB (MAX_SSE_BUFFERED_BYTES, the same limit as the 2026-07-28 listen streams on feat: implement MCP 2026-07-28 alongside the handshake revisions #170) is waiting for the client, the stream is destroyed. The events are already in the session history, so the client reconnects with Last-Event-ID and misses nothing. The destroyed stream is removed from the session like any other dead stream, so the reconnect is not refused with 409. Node's own writable buffer is the queue. There is no second queue in front of it, because the history already does that job.
• The Last-Event-ID replay waits for drain (or close) whenever write() returns false, instead of writing the whole backlog at once. A backlog bigger than 1 MB is normal on reconnect. Closing the stream for it would make a client that is reading fine reconnect forever.

Notes for review:

• While a replay waits for a slow reader, live events written in the meantime still count toward the 1 MB limit. So a client that stalls during the replay is closed as soon as live traffic arrives. Without live traffic it holds at most one write's worth of data.
• A stream closed during the replay is only cleaned up properly together with Disconnecting during a Last-Event-ID replay leaves a dead SSE stream and the session answers 409 forever #334 (PR fix(sse): drop a legacy SSE stream whose client left during setup #351). That PR registers the close handler before the replay. Merging fix(sse): drop a legacy SSE stream whose client left during setup #351 first is best. The two do not overlap textually.
• Live events written while a replay waits can reach the client before the rest of the replayed ones. The live events could already overtake the replay while getMessagesFrom was awaited, so this is not new. Event ids still let the client resume correctly.
• The diff in sendSSEToStreams only changes the write call inside the loop, to keep it clear of fix(sse): allocate event ids atomically in the session store (#317) #325.

Tests

test/sse-backpressure.test.ts, real server with raw sockets:

• a stream that stops reading under 400 × 64 KB broadcasts is destroyed, and the server buffers at most ~1 MB for it (main: 25 MB, stream left open)
• after that, a new GET for the session gets 200 (main: 409)
• a ~3 MB Last-Event-ID replay reaches a client that keeps reading, complete and without the stream being closed
• a ~3 MB replay to a client that stops reading is not queued whole on the server (main: 3.1 MB buffered)

Lint, typecheck and the full suite pass locally (770 tests). The new file passed 5 out of 5 repeated runs.

Fixes #316

🤖 Generated with Claude Code

https://claude.ai/code/session_01LmhsFjk8W96X2PvmShmDm9