Activity

1. maxisbey

   added

   triageQueued for automated analysis — bot will process and remove this labelQueued for automated analysis — bot will process and remove this label

   on May 31, 2026
2. mcp-claude commented on Jun 1, 2026

   

   mcp-claudebot

   on Jun 1, 2026 – with mcp-claude

   More actions

   can't reproduce on linux + cpython 3.14.5 against origin/v1.x (where mcp.server.fastmcp.FastMCP still exists; on main it was renamed to mcp.server.mcpserver.MCPServer in #1951 / 65c614e but the transport plumbing is unchanged). a 30-sequential-session driver completes 30/30 in ~80ms each, no slowdown — matching the reporter's own caveat that linux wasn't validated and that epoll loop semantics might mask it. without a windows host or a runnable reproducer attached here, this can't be confirmed against the sdk.

   one factual correction worth flagging before any fix lands: the writeup says "raw mcp.server.lowlevel.Server writes text/event-stream directly via its own ASGI write loop without ever instantiating EventSourceResponse." that's not how the code is structured. both FastMCP.streamable_http_app() and the raw lowlevel path delegate to StreamableHTTPSessionManager → StreamableHTTPServerTransport in src/mcp/server/streamable_http.py, which instantiates sse_starlette.EventSourceResponse at three sites (POST-with-SSE, standalone GET, resumption replay). there is no separate sse_starlette integration in the wrapper layer. whatever explains the "raw passes 30/30, wrapper hangs at 5" delta on windows, it isn't a different EventSourceResponse instantiation site.

   what would unblock investigation: a single-file reproducer attached to this issue that hangs on windows + 3.14, and the python -m asyncio ps dump taken against an SDK-only repro (not the PrefectHQ fork — they ship a different sse_starlette pin and additional session middleware that may dominate the difference). until then this stays needs-repro.

   repro script (run as `python repro.py`, set SESSIONS/TIMEOUT/PORT env vars to tune)

   """
   Reproducer for issue #2653: FastMCP HTTP transport hang after ~5 sequential sessions.
   
   Spawns a streamable HTTP server with FastMCP, then runs N sequential sessions
   hitting initialize -> tools/list -> close. Reports the iteration each one
   completes at. If the bug reproduces, sessions stop completing partway through.
   """
   from __future__ import annotations
   
   import asyncio
   import contextlib
   import os
   import sys
   import threading
   import time
   
   import uvicorn
   from mcp import ClientSession
   from mcp.client.streamable_http import streamablehttp_client
   from mcp.server.fastmcp import FastMCP
   
   
   SESSIONS = int(os.environ.get("SESSIONS", "30"))
   TIMEOUT_PER_SESSION = float(os.environ.get("TIMEOUT", "5"))
   PORT = int(os.environ.get("PORT", "8765"))
   
   
   def build_server() -> FastMCP:
       mcp = FastMCP(name="repro", port=PORT, host="127.0.0.1")
   
       @mcp.tool()
       def add(a: int, b: int) -> int:
           return a + b
   
       @mcp.tool()
       def echo(s: str) -> str:
           return s
   
       return mcp
   
   
   async def run_one_session(idx: int) -> None:
       url = f"http://127.0.0.1:{PORT}/mcp"
       async with streamablehttp_client(url) as (read, write, _get_session_id):
           async with ClientSession(read, write) as session:
               await session.initialize()
               tools = await session.list_tools()
               assert any(t.name == "add" for t in tools.tools)
               res = await session.call_tool("add", {"a": idx, "b": 1})
               assert res.content
   
   
   async def driver() -> None:
       for i in range(SESSIONS):
           t0 = time.monotonic()
           try:
               await asyncio.wait_for(run_one_session(i), timeout=TIMEOUT_PER_SESSION)
           except asyncio.TimeoutError:
               elapsed = time.monotonic() - t0
               print(f"HANG at session #{i + 1} after {elapsed:.1f}s", flush=True)
               return
           except Exception as e:
               elapsed = time.monotonic() - t0
               print(f"ERROR at session #{i + 1} after {elapsed:.1f}s: {type(e).__name__}: {e}", flush=True)
               return
           elapsed = time.monotonic() - t0
           print(f"session #{i + 1} ok in {elapsed * 1000:.0f}ms", flush=True)
       print(f"all {SESSIONS} sessions completed", flush=True)
   
   
   def run_server_in_thread(mcp: FastMCP) -> threading.Thread:
       def _run():
           app = mcp.streamable_http_app()
           config = uvicorn.Config(app, host="127.0.0.1", port=PORT, log_level="warning")
           server = uvicorn.Server(config)
           server.run()
   
       t = threading.Thread(target=_run, daemon=True)
       t.start()
       return t
   
   
   async def wait_for_server() -> None:
       import httpx
       deadline = time.monotonic() + 10
       while time.monotonic() < deadline:
           try:
               async with httpx.AsyncClient(timeout=1.0) as client:
                   await client.get(f"http://127.0.0.1:{PORT}/mcp")
                   return
           except (httpx.ConnectError, httpx.ReadTimeout):
               await asyncio.sleep(0.1)
       raise RuntimeError("server didn't come up")
   
   
   async def main() -> None:
       mcp = build_server()
       run_server_in_thread(mcp)
       await wait_for_server()
       print(f"server up, running {SESSIONS} sequential sessions", flush=True)
       await driver()
   
   
   if __name__ == "__main__":
       with contextlib.suppress(KeyboardInterrupt):
           asyncio.run(main())
       sys.exit(0)

   linux + cpython 3.14.5 run on origin/v1.x (6213787) — 30/30 pass

   $ python repro.py
   server up, running 30 sequential sessions
   session #1 ok in 77ms
   session #2 ok in 83ms
   session #3 ok in 79ms
   session #4 ok in 80ms
   session #5 ok in 87ms
   ...
   session #28 ok in 74ms
   session #29 ok in 82ms
   session #30 ok in 72ms
   all 30 sessions completed
   

   asyncio policy in the venv is _UnixDefaultEventLoopPolicy (epoll). on origin/main the same shape with MCPServer and streamable_http_client also passes 30/30.

   where EventSourceResponse actually lives

   src/mcp/server/streamable_http.py instantiates sse_starlette.EventSourceResponse at:

   • _handle_post_request SSE branch (line ~617 on main, ~627 on v1.x) — per-POST stream
   • _handle_get_request (line ~726 on main, ~736 on v1.x) — standalone server-initiated stream
   • _replay_events (line ~931 on main, ~944 on v1.x) — last-event-id replay

   FastMCP.streamable_http_app() (v1.x) and MCPServer.streamable_http_app() (main) both build a starlette app whose /mcp endpoint is StreamableHTTPASGIApp(self._session_manager) where self._session_manager is a StreamableHTTPSessionManager. the raw lowlevel example you cite calls the same StreamableHTTPSessionManager.handle_request ASGI entrypoint. there is no second EventSourceResponse code path.
3. mcp-claude

   added

   bugSomething isn't workingSomething isn't working

   needs reproneeds additional information to be able to reproduce bugneeds additional information to be able to reproduce bug

   and removed

   triageQueued for automated analysis — bot will process and remove this labelQueued for automated analysis — bot will process and remove this label

   on Jun 1, 2026
4. colinlabrooy commented on Jun 10, 2026

   

   colinlabrooy

   on Jun 10, 2026

   Last edited by colinlabrooy

   Author

   More actions

   A small follow-up — a re-confirmation and a caution that may save others time.

   Re-confirmation: no repro at 30 sessions. On the same Windows 11 (26200) / Python 3.14 box, a fresh 30-cycle reconnect soak (sequential connect → call → disconnect against a Streamable-HTTP server) passed 30/30 with the standing GET stream live — consistent with the Linux 30/30 above and the earlier 110-session run, so the hang stays a Windows/Proactor timing heisenbug here. For completeness I also ran it with the standing GET stream retired (server returns 405 on GET, so _handle_get_request() / EventSourceResponse is never entered): also 30/30. With the baseline already green that isn't decisive on its own — it's just the result you'd expect if the standalone GET-stream teardown is the locus (one of the three EventSourceResponse sites noted above), and it lines up with stateless_http=True as the practical mitigation.

   Caution for anyone building a minimal reproduction. While writing the soak I hit a hang that looked exactly like the reported "~session #12" wall — and it turned out to be a confound in my own harness, not the server: I was capturing the server subprocess's stdout/stderr through an undrained subprocess.PIPE. uvicorn emits ~5 access-log lines per reconnect cycle, and around cycle ~12 that fills the OS pipe buffer (~64 KB on Windows); the server then blocks on its own log write and stops servicing requests — presenting identically to the deadlock under test. Draining the sink (temp file / DEVNULL / reader thread) made it disappear and the soak ran 30/30. I flag it only because a repro driver that pipes server output without draining will produce a false positive that mimics #12 — worth ruling out before attributing a new "#12 hang" to this issue. It does not explain away the original capture (the FastMCP companion, PrefectHQ/fastmcp#4192, has the asyncio task dump with non-pipe sinks).

   (Cross-posted to PrefectHQ/fastmcp#4192.)
5. isheng-eqi commented on Jul 6, 2026

   

   isheng-eqi

   on Jul 6, 2026

   More actions

   I can reproduce this on Windows 11 + Python 3.13 — the deadlock at session #5 is consistent with the investigation in PrefectHQ/fastmcp#4192.

   I have experience debugging concurrency/deadlock issues in Python async code (previously fixed a cron double-execution race condition). Running on Windows natively means I can iterate on the fix without cross-OS guesswork.

   I'd like to work on this. Happy to start with a clean repro script and trace the deadlock through the HTTP transport layer. Let me know if I should go ahead.
6. isheng-eqi

   added a commit that references this issue on Jul 7, 2026

   fix: use set of CancelScopes to prevent concurrent GET-start race

   ...

   3c0d47b