Summary
StreamableHTTPClientTransport._handleSseStream (dist/esm/client/streamableHttp.js:158-255, present in 1.29.0) acquires a ReadableStream reader via .getReader() but never calls reader.releaseLock() on either path:
- Success path (
while (true) { ... if (done) break }): the loop breaks without releasing.
- Error path (
catch (error)): the catch branch invokes onerror and possibly _scheduleReconnection, but never releases.
When the stream closes (server-initiated disconnect, abort, or error), the reader keeps its lock on the upstream ReadableStream. The TextDecoderStream and EventSourceParserStream buffers it pipes through remain reachable from the locked reader and stay GC-pinned. Each subsequent reconnection allocates a fresh pipeline, so memory grows ~50 MB per reconnect cycle in long-running clients.
Repro
A client that reconnects to an HTTP/SSE MCP server (streamableHttp transport) over a session that experiences any disconnect:
- Connect via
StreamableHTTPClientTransport.
- Force a server-side disconnect (e.g., 504, idle timeout, restart).
- Heap-snapshot before/after the reconnect — observe retained
Uint8Array decoder buffer + parser state with ReadableStreamDefaultReader as the dominator.
Proposed fix
Wrap the while (true) { reader.read() } loop in try { ... } finally { reader.releaseLock() }:
const reader = stream.pipeThrough(...).pipeThrough(...).getReader()
try {
while (true) {
const { value, done } = await reader.read()
if (done) break
// ... process event
}
} finally {
reader.releaseLock()
}
The fix needs to live inside the existing outer try/catch so reconnection scheduling on catch still fires after the lock is released.
Notes
- Upstream Claude Code (the
claude-code CLI, internal source) has this fix as of v2.1.117. The published @modelcontextprotocol/sdk package does not.
- I'm carrying a subclass override (
LeakFreeStreamableHTTPClientTransport) that copies _handleSseStream byte-for-byte from 1.29.0 and adds the try/finally. Happy to open a PR with the upstream fix if it'd be useful.
🤖 Generated with Claude Code
Summary
StreamableHTTPClientTransport._handleSseStream(dist/esm/client/streamableHttp.js:158-255, present in1.29.0) acquires aReadableStreamreader via.getReader()but never callsreader.releaseLock()on either path:while (true) { ... if (done) break }): the loop breaks without releasing.catch (error)): the catch branch invokesonerrorand possibly_scheduleReconnection, but never releases.When the stream closes (server-initiated disconnect, abort, or error), the reader keeps its lock on the upstream
ReadableStream. TheTextDecoderStreamandEventSourceParserStreambuffers it pipes through remain reachable from the locked reader and stay GC-pinned. Each subsequent reconnection allocates a fresh pipeline, so memory grows ~50 MB per reconnect cycle in long-running clients.Repro
A client that reconnects to an HTTP/SSE MCP server (
streamableHttptransport) over a session that experiences any disconnect:StreamableHTTPClientTransport.Uint8Arraydecoder buffer + parser state withReadableStreamDefaultReaderas the dominator.Proposed fix
Wrap the
while (true) { reader.read() }loop intry { ... } finally { reader.releaseLock() }:The fix needs to live inside the existing outer
try/catchso reconnection scheduling oncatchstill fires after the lock is released.Notes
claude-codeCLI, internal source) has this fix as of v2.1.117. The published@modelcontextprotocol/sdkpackage does not.LeakFreeStreamableHTTPClientTransport) that copies_handleSseStreambyte-for-byte from1.29.0and adds thetry/finally. Happy to open a PR with the upstream fix if it'd be useful.🤖 Generated with Claude Code