StreamableHTTP server accumulates CLOSE_WAIT sockets behind reverse proxy due to missing disconnect cleanup

[simpson1045]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

When running a StreamableHTTP MCP server behind a reverse proxy (nginx, Nginx Proxy Manager, etc.), TCP sockets accumulate in CLOSE_WAIT state after each tool call. After 10-20 calls, the server becomes unresponsive and stops accepting new connections, requiring a full process restart.

The root cause is in StreamableHTTPServerTransport._handle_post_request() — when the reverse proxy closes its side of the connection after a completed request, the sse_writer coroutine remains blocked on an in-memory stream (request_stream_reader) and never exits. Because the ASGI callable never fully returns, uvicorn never closes the server side of the socket, leaving it in CLOSE_WAIT indefinitely.

Environment

• MCP Python SDK: 1.28.0
• Python: 3.13
• Server: uvicorn (via mcp.run(transport="streamable-http"))
• Reverse proxy: Nginx Proxy Manager (nginx-based)
• OS: Windows 11 (but the bug is platform-independent)

To Reproduce

1. Set up a FastMCP server with StreamableHTTP transport behind any reverse proxy (nginx, NPM, Caddy, etc.)
2. Connect a client and make several tool calls
3. Monitor sockets: netstat -ano | findstr <port>
4. Observe CLOSE_WAIT connections accumulating after each call
5. After ~10-20 calls, the server stops responding to new connections

TCP    0.0.0.0:8849           0.0.0.0:0              LISTENING       43056
TCP    192.168.0.150:8849     192.168.0.248:41992    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42224    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42264    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42274    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42284    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42292    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42394    CLOSE_WAIT      43056
TCP    192.168.0.150:8849     192.168.0.248:42402    CLOSE_WAIT      43056
...

Root Cause Analysis

In streamable_http.py, the SSE response path in _handle_post_request() (~line 380):

async with anyio.create_task_group() as tg:
    tg.start_soon(response, scope, receive, send)
    session_message = self._create_session_message(message, request, request_id, protocol_version)
    await writer.send(session_message)

When the reverse proxy closes the TCP connection:

1. EventSourceResponse (from sse-starlette) detects the disconnect via ASGI receive() and its task completes
2. However, sse_writer() is still alive inside the response, blocked on async for event_message in request_stream_reader — this is an in-memory stream, not a socket, so it has no awareness of the TCP disconnect
3. Nobody closes request_stream_reader, so sse_writer hangs indefinitely
4. The ASGI callable never fully returns because the streams are never cleaned up
5. uvicorn never sends FIN on the server side → socket remains in CLOSE_WAIT

Additionally, session_idle_timeout in StreamableHTTPSessionManager defaults to None (no timeout), meaning orphaned sessions are never reaped. The docstring itself recommends 1800 seconds for most deployments, but the default doesn't reflect this.

Proposed Fix

1. Transport layer — disconnect-aware cleanup in _handle_post_request()

Wrap the response() call so that when it returns (whether from normal completion or client disconnect), the request streams are immediately cleaned up, unblocking sse_writer:

async with anyio.create_task_group() as tg:
    async def run_response_with_cleanup():
        try:
            await response(scope, receive, send)
        finally:
            # Response finished — client disconnected or normal completion.
            # Close request streams to unblock sse_writer if it's still
            # waiting on the in-memory stream.
            await self._clean_up_memory_streams(request_id)
            writer_ref = self._sse_stream_writers.pop(request_id, None)
            if writer_ref:
                writer_ref.close()

    tg.start_soon(run_response_with_cleanup)
    session_message = self._create_session_message(
        message, request, request_id, protocol_version
    )
    await writer.send(session_message)

When the client disconnects:

1. response() returns (EventSourceResponse detects disconnect)
2. finally block fires, closes request streams
3. sse_writer unblocks with ClosedResourceError (which it already catches gracefully)
4. sse_writer exits cleanly
5. ASGI callable returns → uvicorn sends FIN → socket closes properly

2. Session manager — sensible default for session_idle_timeout

In streamable_http_manager.py, change the default from None to 1800 (30 minutes), consistent with the existing docstring recommendation:

session_idle_timeout: float | None = 1800,

This provides a safety net: even if disconnect detection misses an edge case, orphaned sessions will eventually be cleaned up rather than accumulating indefinitely.

Related Issues

• Server hangs when shutting down if a connection is still open #1272 — Server hangs when shutting down if a connection is still open (same family: connection lifecycle cleanup)
• Errors during cleanup when using streamablehttp_client with AsyncExitStack instead of async with #831 — Errors during cleanup when using streamablehttp_client with AsyncExitStack
• SSE: ConnectionClosed exception after session disconnect #1227 — SSE: ConnectionClosed exception after session disconnect

Impact

This affects every StreamableHTTP MCP server deployed behind a reverse proxy. Direct connections (localhost) are less affected because the OS handles TCP teardown more aggressively, but the underlying resource leak (orphaned in-memory streams and sessions) still exists.

[Ewertonslv]

I traced this against current main and can confirm the root cause, with a couple of refinements that matter for the fix and for writing a regression test.

Where it parks. _run_sse_writer only leaves its loop on one of:

• a terminal message — isinstance(event_message.message, JSONRPCResponse | JSONRPCError) → break (streamable_http.py:299-300), or
• the request stream closing → the async for event_message in request_stream_reader (:297) ends, or
• ClosedResourceError (:301).

Its finally (:305-308) is what pops _sse_stream_writers and calls _clean_up_memory_streams. So normal completion is fine: the writer breaks on the terminal response, closes its streams, the SSE body ends, and the ASGI callable returns.

The leak path is specifically response task ends without the writer having seen a terminal message, and without the disconnect being surfaced as a cancellation of the data sender. The request_stream_reader is an in-memory MemoryObjectReceiveStream — it has no awareness of TCP state — so nothing wakes the async for, the data-sender task stays parked, the task group at :629-633 never completes, and the ASGI callable never returns → uvicorn never sends FIN → CLOSE_WAIT. Behind a reverse proxy the upstream FIN often isn't surfaced to the app as an ASGI http.disconnect, which is why it reproduces there and not on localhost.

The proposed fix shape is sound. Wrapping the response(scope, receive, send) call (:630) in a try/finally that calls await self._clean_up_memory_streams(request_id) works because _clean_up_memory_streams is idempotent (guarded by if request_id in self._request_streams, :377) and aclose()-es the request stream (:380-381), which unblocks _run_sse_writer via ClosedResourceError — already handled at :301. So it composes cleanly with the writer's own finally regardless of ordering.

One caution on part 2. Changing StreamableHTTPSessionManager's session_idle_timeout default from None → 1800 is a public behavior change — it would start reaping stateful sessions that are legitimately idle for >30 min. Worth treating as a separate decision from the transport-layer cleanup, which is the actual fix here.

On a regression test. This is the tricky part: a faithful unit repro can't just feed an http.disconnect, because then sse-starlette cancels the data sender and _run_sse_writer's own finally already cleans up (no leak). The test has to drive the transport so the response task returns while the writer is still parked on :297 — e.g. an ASGI send/response that completes without a terminal JSON-RPC message having been routed — and then assert request_id is gone from both _request_streams and _sse_stream_writers. Happy to put that together.

I have the transport-layer fix + such a test ready to go — glad to open a PR if a maintainer wants to take it.