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. 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.
3. 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}
4. maxisbey

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

   

   Jaswanth1902

   on Oct 2, 2026 · Hidden as spam

   show commentMore actions