René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"streamable_http_client: one concurrent request HTTPStatusError tears down sibling requests","articleBody":"### Initial Checks\n\n- [x] I confirm that I'm using the latest version of MCP Python SDK\n- [x] I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue\n\n### Description\n\nWhen using `streamable_http_client` with concurrent JSON-RPC requests over the same Streamable HTTP session, an HTTP error from one request can escape the transport task group and disrupt unrelated sibling requests that are still waiting for their responses.\n\nThis happens because `post_writer()` starts each JSON-RPC request as a task: `tg.start_soon(handle_request_async)` and `_handle_post_request()` calls: `response.raise_for_status()`\n\nIf one concurrent request receives a non-2xx HTTP response, e.g. 400 Bad Request, the resulting `httpx.HTTPStatusError` escapes from that per-request task into the shared task group. The task group then exits with:\n`ExceptionGroup: unhandled errors in a TaskGroup` (1 sub-exception)\n\nAt the same time, sibling requests that were still waiting in `ClientSession.send_request()` can be cancelled/disrupted. In our production traces, the sibling request stack showed:\n\n```\nFile \".../mcp/shared/session.py\", line 292, in send_request\n  response_or_error = await response_stream_reader.receive()\n\nFile \".../anyio/streams/memory.py\", line 117, in receive\n  return self.receive_nowait()\n\nFile \".../anyio/streams/memory.py\", line 112, in receive_nowait\n  raise WouldBlock\n\nanyio.WouldBlock\n```\nThe `WouldBlock` is not the root cause by itself; it appears because the sibling request was waiting for a response when the transport/session was torn down by the other request's HTTP error.\n\n#### Expected Behavior\nA non-2xx HTTP response for one request should be scoped to that request only.\n\nFor example, if request A receives HTTP 400, request A should receive a request-level exception or MCP error, but request B should continue waiting for its own response and should be able to complete successfully.\n\n#### Actual Behavior\nA single request's HTTPStatusError escapes the shared transport task group and can poison the whole Streamable HTTP session, cancelling or disrupting sibling requests.\n\n#### Why this matters\nParallel tool calls are a common and useful pattern for MCP clients. In our agent, we intentionally allow parallel MCP tool calls to reduce latency. If one tool call gets a server-side HTTP 400 while another valid tool call is still in flight, the valid sibling call can fail too.\n\n#### Related Issues\nThis seems related to but more specific than:\n\nhttps://github.com/modelcontextprotocol/python-sdk/issues/2110\nhttps://github.com/modelcontextprotocol/python-sdk/issues/1805\n\nThose discuss non-2xx propagation and stream cleanup races. This issue is specifically about concurrent Streamable HTTP requests where one request's HTTP error escapes the per-request boundary and tears down sibling in-flight requests.\n\n### Example Code\n\n```Python\n\n```\n\n### Python \u0026 MCP Python SDK\n\n```Text\nPython 3.12\nMCP Python SDK 1.26.0\n\nI also inspected 1.27.1, which is currently the latest PyPI release, and the same relevant logic appears to still be present.\n```","author":{"url":"https://github.com/Jarda8","@type":"Person","name":"Jarda8"},"datePublished":"2026-05-15T11:41:52.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/2604/python-sdk/issues/2604"}