modelcontextprotocol / modelcontextprotocol/python-sdk

Streamable HTTP client stays closed after an interrupted response and raises ExceptionGroup on cleanup

Open
#3,522 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

v1 v2
Dominant language
Python
Stars
24.3k
Forks
4k
Avg merge
1d 1h
Merged PRs (30d)
31

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
  1. disconnect interrupts its active HTTP response.
  2. Python reports the request failure.
  3. A following ping fails immediately with MCPError: Connection closed.
  4. Context cleanup raises ExceptionGroup: unhandled errors in a TaskGroup whose nested cause is httpx2.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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the streamable_http_client entry point in mcp.client.streamable_http and run the provided repro.py against mcp-failure-lab. Trace how the interrupted disconnect response affects the client and task-group cleanup; done means the disconnect failure is reported, a subsequent ping succeeds on the same client, and context exit raises no ExceptionGroup.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.