Repository navigation
POST failure identical to task cancellation in streamable HTTP client #3560
Description
Initial Checks
- I confirm that I'm using the newest release of my line (the latest 2.x, or the latest 1.x if I'm still on v1)
- I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue
Release line
2.x (current stable)
Description
#2047 made non-2xx responses request-scoped (#2604). A POST that raises before there is any response -- connection refused or similar -- still escapes handle_request_async into post_writer's task group. The waiting caller gets CancelledError with WouldBlock as __context__, identical to what happens in cancellation. The ConnectError never reaches the caller; it only appears in the ExceptionGroup raised when streamable_http_client exits.
A caller therefore can't tell "server went away" from "this task is being cancelled", and can't retry the first without swallowing the second.
Expected: the failed call raises MCPError with the transport exception reachable as its cause. External cancellation still raises CancelledError.
#1830 reported this and was closed after 1.25.0 appeared to produce an ExceptionGroup instead. Both happen: the caller gets CancelledError, and the ExceptionGroup surfaces later at transport exit. #1830's repro used only sse_client.
Example Code
# /// script
# requires-python = ">=3.11"
# dependencies = ["mcp>=2.2.0", "uvicorn"]
# ///
"""A: kill the server mid-session, then call a tool. B: cancel an in-flight call.
Prints the exception each caller receives, with its __cause__/__context__ chain.
"""
import asyncio
import importlib.metadata
import multiprocessing
import socket
import time
import uvicorn
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client
from mcp.server import MCPServer
HOST = "127.0.0.1"
def get_free_port() -> int:
with socket.socket() as sock:
sock.bind((HOST, 0))
return int(sock.getsockname()[1])
def run_server(port: int) -> None:
server = MCPServer("repro", log_level="CRITICAL")
@server.tool()
def echo(text: str) -> str:
return text
@server.tool()
async def slow() -> str:
await asyncio.sleep(30)
return "done"
uvicorn.run(server.streamable_http_app(), host=HOST, port=port, log_level="critical")
def start_server() -> tuple[multiprocessing.Process, str]:
port = get_free_port()
proc = multiprocessing.Process(target=run_server, args=(port,), daemon=True)
proc.start()
deadline = time.monotonic() + 30
while time.monotonic() < deadline:
try:
with socket.create_connection((HOST, port), timeout=0.25):
return proc, f"http://{HOST}:{port}/mcp"
except OSError:
time.sleep(0.05)
raise RuntimeError("server did not come up")
def report(label: str, exc: BaseException) -> None:
print(f" {label}:")
seen: set[int] = set()
current: BaseException | None = exc
depth = 2
while current is not None and id(current) not in seen:
seen.add(id(current))
print(f"{' ' * depth}{type(current).__name__}: {current!r}")
if isinstance(current, BaseExceptionGroup):
for sub in current.exceptions:
print(f"{' ' * (depth + 1)}| {type(sub).__name__}: {sub!r}")
current = current.__cause__ or current.__context__
depth += 1
async def scenario_server_dies() -> None:
proc, url = start_server()
try:
async with streamable_http_client(url) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
await session.call_tool("echo", {"text": "before"})
proc.kill()
proc.join()
try:
await session.call_tool("echo", {"text": "after"})
except BaseException as exc:
report("caller", exc)
return
print(" caller: no exception")
except BaseException as exc:
report("streamable_http_client exit", exc)
finally:
if proc.is_alive():
proc.kill()
async def scenario_external_cancel() -> None:
proc, url = start_server()
try:
async with streamable_http_client(url) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
task = asyncio.create_task(session.call_tool("slow", {}))
await asyncio.sleep(0.5)
task.cancel()
try:
await task
except BaseException as exc:
report("caller", exc)
return
print(" caller: no exception")
except BaseException as exc:
report("streamable_http_client exit", exc)
finally:
if proc.is_alive():
proc.kill()
async def main() -> None:
print(f"mcp {importlib.metadata.version('mcp')}")
print("A: server killed mid-session")
await scenario_server_dies()
print("B: in-flight call cancelled externally")
await scenario_external_cancel()
if __name__ == "__main__":
multiprocessing.set_start_method("spawn")
asyncio.run(main())Output from running the above:
mcp 2.2.0
A: server killed mid-session
caller:
CancelledError: CancelledError('Cancelled via cancel scope 10bbefe30')
WouldBlock: WouldBlock()
streamable_http_client exit:
ExceptionGroup: ExceptionGroup('unhandled errors in a TaskGroup', [ConnectError('All connection attempts failed')])
| ConnectError: ConnectError('All connection attempts failed')
CancelledError: CancelledError('Cancelled via cancel scope 10bbefe30')
CancelledError: CancelledError("Cancelled via cancel scope 10bc90410 by <Task cancelling name='Task-1' ...>")
B: in-flight call cancelled externally
caller:
CancelledError: CancelledError()
WouldBlock: WouldBlock()
Python & MCP Python SDK
Python 3.13.14, macOS arm64
mcp 2.2.0
Activity
charles-dyfis-net commentedon Sep 22, 2026
I have a local patch I've been using to address this issue, and would be glad to submit it as a PR if y'all were to assign the ticket my way.
anilloutombam commentedon Sep 27, 2026
I reproduced the same task-group failure pattern with
mcp2.2.0 while testing the publishedmcp-failure-lab@0.11.0package.The
session_losstool interrupted its active legacy Streamable HTTP response. Across three runs:Connection closedor the same cancellation;ExceptionGroupeach time;The equivalent TypeScript test kept the unrelated server session usable, which points to client task-group propagation rather than server-side session leakage.
Full environment, method, and results: https://github.com/anilloutombam/mcp-failure-lab/blob/main/docs/compatibility/v0.11.0.md
josendfa commentedon Oct 13, 2026
Related: #1401 (which #3584 was filed against) and #3522 (the same teardown on 2.x, from a
RemoteProtocolError).This also cancels every other request in flight on the session, not only the one whose POST raised, and on 1.x a per-call
read_timeout_secondsturns it into a delayed failure of later requests. Reproduced on the newest release of both lines, 1.30.0 (httpx 0.28.1) and 2.3.0 (httpx2 2.13.1), and on 2.1.1, Python 3.13.Setup: a server in JSON response mode, so a POST's headers arrive only when its tool returns. The client's HTTP read timeout is 3 s.
slowtakes 8 s,medium2.5 s, andechois instant.A. A concurrent call outlives another call's read timeout.
slowhas no per-call timeout.mediumis sent 1 s later and would finish at 3.5 s. At 3 s,slow'sReadTimeoutescapes its POST task, and the transport's task group cancels everything:B (1.x). A call made after a per-call timeout.
slowis called withread_timeout_seconds=0.5, and the caller gets its timeout at 0.5 s. The POST is not ended, though: it stays open until its HTTP read timeout.mediumis sent at 1.5 s as a new request, and is cancelled at about 3 s, when the abandoned POST'sReadTimeoutfires. So doesecho. The server completesmediumanyway. On 2.3.0 against a 2.3.0 server, B does not reproduce: in a session opened withinitialize(), below the 2026-07-28 envelope, the client sendsnotifications/cancelledforslowand the server ends that request, so its POST never reaches the read timeout. (At the 2026-07-28 era the client aborts the POST locally instead.) It would still reproduce against any server that does not end a cancelled request's POST.Why it matters. A session carries concurrent tool calls, for example an agent's parallel tool use. Any one POST that sees a transport error before its headers (a slow tool against a read timeout, or a response lost in transit) cancels all the others. Each of those callers is told its call was cancelled while the server may have completed it. For a mutating tool that means a write that happened is reported as failed, and the caller cannot tell which. The session is then unusable, and the error that caused it only surfaces as an
ExceptionGroupon exit.Where. 1.30.0:
post_writerruns each request astg.start_soon(handle_request_async)(client/streamable_http.pyL587) in the transport's single task group (L672), and nothing in_handle_post_request(L355) catches the error fromstream_within_origin(L361). 2.3.0: the same shape._run_request_post(L346–361) wraps the POST in the_InFlightPostcancel scope, but in atry/finallywith noexcept; it is started into the transport-wide group (L680, created at L771). The header read is at L370.Fix. The approach in #3584 (auto-closed, unreviewed) covers this: catch the transport error in
_handle_post_request, resolve only that request (CONNECTION_CLOSED, naming the cause), and drop a failed notification without endingpost_writer. Its tests includetest_post_transport_error_on_one_call_leaves_a_concurrent_call_in_flight. A backport to v1.x would matter to anyone held on 1.x by a downstream pin.The analysis and the script were prepared with AI assistance; I reviewed both and ran the script myself.
Reproduction script (runs unchanged on 1.x and 2.x)
Run with:
uv run --with "mcp==1.30.0" --with uvicorn python mcp_post_read_timeout_cascade.py(ormcp==2.3.0).