Streamable HTTP on Windows: after a tool raises a non-ToolError, no request is answered again (2.1.0+, 2.0.1 fine) #3586

Activity

1. claude

   added

   v2Affects the v2 line (2.x on main)Affects the v2 line (2.x on main)

   on Sep 26, 2026
2. Ben-Home commented on Sep 28, 2026

   

   Ben-Home

   on Sep 28, 2026

   More actions

   The version and platform matrix here is very clean and it points at the streamable-HTTP response writer rather than tool dispatch itself: only non-ToolError exceptions trigger it, only Windows triggers it, 2.0.1 predates the break, and stdio is unaffected. On the same machine ToolError raises answer normally, so the dispatch boundary converts ToolError fine; the unexpected-exception path is the one that never emits a result event.

   My hypothesis: on the unexpected-exception path, the exception escapes the response writer task before the JSON-RPC error envelope (or the terminal SSE event) is written, and on Windows the Proactor event loop surfaces the resulting connection reset differently than Linux's selector loop, which is why the same code serves fine on WSL. The "server stops answering everything, including initialize on a new session" detail suggests the session is left poisoned after the writer task dies.

   Two quick tests that would split the bug space in half:

   1. Run the server with the selector policy: asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy()) before startup. If 2.2.0 then behaves like 2.0.1, it is a Proactor-specific write path or task exception handling issue.
   2. Wrap the handler in a shim that converts every exception to a ToolError and confirm the session keeps serving. That proves the boundary conversion is the fix locus.

   The invariant that should hold: any handler exception is caught at the dispatch boundary, converted into CallToolResult(isError=True), and the stream is closed with the terminal event, so a dying worker task can never take the session down with it. That is the rule we enforce on the CorpusIQ MCP server (corpusiq.io), which runs 36 connectors over streamable HTTP: no exception ever escapes the tool-call boundary.
3. liwenjie200543 commented on Sep 30, 2026

   

   liwenjie200543

   on Sep 30, 2026

   More actions

   I reproduced the hang with the reproducer above on Windows 10 (Python 3.12.14, mcp 2.2.0): 3/3 runs stop answering at async_tool(x=-1), and the server ignores everything afterwards — matching the report.

   While bisecting the setup I found the trigger is the server's stdout channel, not the async tool path itself. Running the identical reproducer with the server's stdout redirected to a file instead of the parent's undrained subprocess.PIPE flips the outcome (verified in 3 consecutive runs): sync_tool(x=-1) and async_tool(x=-1) both answer isError: true in 0.0s and a fresh session initializes immediately.

   Likely mechanism (inference from that experiment, not from a direct stack dump): 2.x crash-path logging writes a full logger.exception traceback (~4 KB) to stdout from inside the event-loop thread. 2.1.0 replaced the old one-line logger.info("Tool %r failed: %r", ...) with that traceback, so two crashes in a row are enough to fill the OS pipe buffer when the consumer drains it only at the end — after that, the next log write blocks the loop thread and the server stops answering. 2.0.1 would wedge the same way under an undrained pipe given enough crash logs; 2.1.0 just gets there after two crashes, which reads like a 2.x async regression.

   If that holds, the operational fix is "don't give an MCP server an undrained stdout" (Docker/CI harnesses drain or drop it), and the SDK-side question for maintainers is whether the crash path still needs the full traceback in the request handler, or whether it should be a single line with exc_info reserved for debug logging. Happy to prepare the latter if wanted.
4. maxisbey commented on Oct 1, 2026

   

   maxisbey

   on Oct 1, 2026

   Contributor

   More actions

   I reproduced this on Windows. The hang comes from how the reproduction script launches the server, not from the SDK: the server's output goes to a pipe that nothing reads, and the server blocks once that pipe is full.

   The script starts the server with stdout=subprocess.PIPE, stderr=subprocess.STDOUT and only reads the pipe after killing the process. On Windows that pipe holds 4096 bytes. Since 2.1.0 an unexpected tool exception is logged with its traceback (#3314), which is 2 to 3 KB, or about 10 KB with rich installed. When that log write doesn't fit, it blocks the event loop thread, so nothing is answered afterwards, new sessions included.

   Three things point at the pipe and not the transport:

   • If the pipe is read while the server runs, or the output goes to a file or DEVNULL, every call answers and the crashes come back as isError: true.
   • If I let it hang and then start reading the pipe, the stuck request completes straight away and the server carries on.
   • The same thing happens without any crash, just later. 2.0.1 stops at the 61st ordinary call, and a bare Starlette app under uvicorn with no MCP code stops at request 74, once the access log has filled the pipe.

   So 2.1.0 reaches the limit sooner because a crash now writes a traceback, but a server whose output goes to a console, a file or a pipe that is being read isn't affected.

   Here's a fixed version of your script. The only change is that the server's output goes straight to server-stderr.log instead of a pipe:

   sdk_hang_repro.py

   """Over streamable-http, a tool that raises anything other than ToolError answers
   with isError as long as the server's output is not left in an unread pipe.
   
   Run with a given SDK version, for example:
       uv run --with "mcp==2.2.0" python sdk_hang_repro.py
   """
   
   import importlib.metadata
   import json
   import os
   import socket
   import subprocess
   import sys
   import time
   from urllib.error import HTTPError
   from urllib.request import Request, urlopen
   
   SERVER = """
   from mcp.server.mcpserver import MCPServer
   import os
   
   mcp = MCPServer("repro")
   
   @mcp.tool()
   def sync_tool(x: int) -> str:
       if x < 0:
           raise ValueError("x must be non-negative")
       return str(x)
   
   @mcp.tool()
   async def async_tool(x: int) -> str:
       if x < 0:
           raise ValueError("x must be non-negative")
       return str(x)
   
   mcp.run(transport="streamable-http", host="127.0.0.1", port=int(os.environ["PORT"]))
   """
   
   ACCEPT = "application/json, text/event-stream"
   
   
   def post(url, payload, session_id=None, timeout=10):
       headers = {"Content-Type": "application/json", "Accept": ACCEPT}
       if session_id:
           headers["Mcp-Session-Id"] = session_id
       req = Request(url, data=json.dumps(payload).encode(), headers=headers, method="POST")
       try:
           with urlopen(req, timeout=timeout) as resp:
               return resp.status, dict(resp.headers), resp.read().decode(errors="replace")
       except HTTPError as exc:
           return exc.code, dict(exc.headers), exc.read().decode(errors="replace")
   
   
   def main():
       with socket.socket() as s:
           s.bind(("127.0.0.1", 0))
           port = s.getsockname()[1]
       # Send the server's output to a file instead of a pipe that is only read at the end.
       log_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), "server-stderr.log")
       log_file = open(log_path, "w", encoding="utf-8")
       proc = subprocess.Popen([sys.executable, "-c", SERVER], env=dict(os.environ, PORT=str(port)),
                               stdout=log_file, stderr=subprocess.STDOUT)
       try:
           for _ in range(120):
               try:
                   with socket.create_connection(("127.0.0.1", port), timeout=0.5):
                       break
               except OSError:
                   time.sleep(0.25)
           url = f"http://127.0.0.1:{port}/mcp"
           print("mcp", importlib.metadata.version("mcp"), "| python", sys.version.split()[0], "|", sys.platform)
           _, headers, _ = post(url, {"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {
               "protocolVersion": "2025-11-25", "capabilities": {}, "clientInfo": {"name": "repro", "version": "0"}}})
           sid = headers.get("mcp-session-id") or headers.get("Mcp-Session-Id")
           post(url, {"jsonrpc": "2.0", "method": "notifications/initialized"}, sid)
           rid = 2
           for tool in ("sync_tool", "async_tool"):
               for x in (1, -1):
                   rid += 1
                   t0 = time.time()
                   try:
                       status, _, body = post(url, {"jsonrpc": "2.0", "id": rid, "method": "tools/call",
                                                    "params": {"name": tool, "arguments": {"x": x}}}, sid)
                       data = [l[6:] for l in body.splitlines() if l.startswith("data: ")]
                       summary = json.loads(data[0])["result"] if data else body[:120]
                       if isinstance(summary, dict):
                           summary = {k: summary[k] for k in ("isError", "content") if k in summary}
                       print(f"{tool}(x={x}): HTTP {status} in {time.time() - t0:.1f}s -> {json.dumps(summary)[:160]}")
                   except Exception as exc:
                       print(f"{tool}(x={x}): NO ANSWER after {time.time() - t0:.0f}s ({type(exc).__name__})")
           # Is the damage confined to the session? Open a fresh one and call a healthy tool.
           t0 = time.time()
           try:
               _, headers, _ = post(url, {"jsonrpc": "2.0", "id": 90, "method": "initialize", "params": {
                   "protocolVersion": "2025-11-25", "capabilities": {}, "clientInfo": {"name": "repro2", "version": "0"}}})
               sid2 = headers.get("mcp-session-id") or headers.get("Mcp-Session-Id")
               print(f"new session: initialize answered in {time.time() - t0:.1f}s")
               post(url, {"jsonrpc": "2.0", "method": "notifications/initialized"}, sid2)
               t0 = time.time()
               status, _, body = post(url, {"jsonrpc": "2.0", "id": 91, "method": "tools/call",
                                            "params": {"name": "sync_tool", "arguments": {"x": 2}}}, sid2)
               print(f"new session, sync_tool(x=2): HTTP {status} in {time.time() - t0:.1f}s -> {body[:100].strip()!r}")
           except Exception as exc:
               print(f"new session: NO ANSWER after {time.time() - t0:.0f}s ({type(exc).__name__})")
       finally:
           proc.kill()
           proc.wait(timeout=10)
           log_file.close()
           with open(log_path, encoding="utf-8", errors="replace") as fh:
               raw = fh.read()
           table = str.maketrans("", "", "┌─┐│└┘╭╮╰╯")
           lines = [l.translate(table).strip() for l in raw.splitlines()]
           keep = [l for l in lines if l and any(k in l for k in ("Traceback", "File ", "Error", "raise ", "exception"))]
           print("server log (filtered):")
           for l in keep[-14:]:
               print("   ", l[:150])
   
   
   if __name__ == "__main__":
       main()

   I'm closing this since it isn't an SDK bug. If you still see it with the output drained or redirected, comment here and I'll reopen it.

   _{AI Disclaimer}
5. maxisbey

   closed this as not plannedon Oct 1, 2026
6. Jaswanth1902 commented on Oct 2, 2026

   

   Jaswanth1902

   on Oct 2, 2026 · Hidden as spam

   show commentMore actions