Repository navigation
Streamable HTTP client stays closed after an interrupted response and raises ExceptionGroup on cleanup #3522
Description
Description
With the current 2.x release, one interrupted Streamable HTTP tool response permanently closes the Python client session. The failing request is reported, but a subsequent normal request on the same client fails with MCPError: Connection closed. Exiting streamable_http_client(...) then raises an unhandled ExceptionGroup from its background task group.
The same MCP server remains healthy. Under the identical sequence, @modelcontextprotocol/sdk@1.30.0 reports the interrupted request and successfully completes the next ping on the same client.
Expected behavior
The interrupted request should fail, while a subsequent request should be able to use a fresh HTTP connection and succeed. Transport cleanup should not raise an additional ExceptionGroup.
Actual behavior
disconnectinterrupts its active HTTP response.- Python reports the request failure.
- A following
pingfails immediately withMCPError: Connection closed. - Context cleanup raises
ExceptionGroup: unhandled errors in a TaskGroupwhose nested cause ishttpx2.RemoteProtocolError: Server disconnected without sending a response.
Comparison
The official TypeScript client 1.30.0 receives TypeError: fetch failed for the deliberately interrupted request, then successfully sends ping through the same client. This suggests the server remains available and the problem is in Python client recovery/cleanup.
I also searched the existing issues. #3494 concerns a server-side incomplete SSE body during initialize, and #3441 concerns an unresolved 1.x request; neither appears to cover this v2 same-client recovery failure.
Minimal reproduction
# Terminal 1
npx mcp-failure-lab@0.9.0 serve --transport http --host 127.0.0.1 --port 43118 --path /mcp
# Terminal 2: save as repro.py, then run: python repro.py
import anyio
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client
URL = "http://127.0.0.1:43118/mcp"
async def main():
try:
async with streamable_http_client(URL) as streams:
async with ClientSession(
streams[0], streams[1], read_timeout_seconds=1.0
) as session:
await session.initialize()
try:
await session.call_tool(
"disconnect", {}, read_timeout_seconds=0.6
)
except BaseException as error:
print("disconnect:", type(error).__name__, error)
# Expected: succeeds. Actual: MCPError: Connection closed
print("ping:", await session.call_tool("ping", {}))
except BaseException as error:
# Actual: ExceptionGroup from streamable_http_client cleanup
print("cleanup:", type(error).__name__, error)
anyio.run(main)Environment
Python 3.12.14; mcp 2.2.0; macOS arm64. Server: mcp-failure-lab 0.9.0; protocol 2026-07-28.
Activity
macrogui commentedon Sep 17, 2026
Confirmed the full reproduction on
main(macOS arm64, Python 3.13, mcp-failure-lab 0.9.0 over HTTP): the interrupteddisconnectcall fails, the followingpinggetsMCPError: Connection closed, and exitingstreamable_http_clientraises theExceptionGroup(nested causehttpx2.RemoteProtocolError).Root cause looks like an unhandled escape path rather than the session lifecycle:
_run_request_postruns each request's POST with no exception guard, so a transport-level failure (server drops the connection before sending a response) propagates out of the per-request task and cancels the transport's task group — the write stream closes, which is what turns every later request intoConnection closed, and the raw error resurfaces as the unhandled TaskGroup exception on cleanup. The contained outcomes (202 Accepted, non-resumable SSE drops, exhausted reconnection) already resolve just the in-flight request via_resolve_abandoned_request; this looks like the one POST failure mode that bypasses that pattern.I have a branch implementing the same containment for HTTP transport errors — catch
httpx2.TransportErroraround the POST exchange in_handle_post_request, resolve the in-flight request withCONNECTION_CLOSED, keep the session usable (verified: the nextpingsucceeds against the failure-lab server, and cleanup no longer raises). Happy to open the PR if that's the direction you want — happy to take a different shape too.