StreamableHTTP client: _handle_reconnection resets attempt counter to 0, causing infinite retry loop
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 78/100
Rechercherichtung
Beginne in streamable_http.py bei _handle_reconnection und verfolge sowohl den erfolgreichen Wiederverbindungs- als auch den Exception-Pfad. Konzentriere dich darauf, wie attempt durch die Rekursion weitergegeben wird. Führe den bereitgestellten Reproducer server.py und client.py aus; abgeschlossen ist die Aufgabe, wenn wiederholt unvollständige Streams nach MAX_RECONNECTION_ATTEMPTS beendet werden und der Aufrufer einen Fehler erhält, anstatt auf unbestimmte Zeit hängen zu bleiben.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Bug Description
_handle_reconnection() in streamable_http.py resets the attempt counter to 0 on line 494 when a reconnection succeeds but the stream ends without delivering a complete response. This makes MAX_RECONNECTION_ATTEMPTS ineffective — the counter only applies to consecutive exceptions, not total reconnection attempts. If the server accepts the connection but the stream drops repeatedly, the client retries forever.
Reproduction
MCP version: 1.26.0 (also confirmed unpatched in 1.27.0 main branch)
SSCE — Minimal reproducer
Server (server.py): A server that accepts SSE connections but closes them before sending a complete response, with a last-event-id header to trigger the reconnection path.
"""Minimal MCP server that drops SSE streams to trigger infinite reconnect."""
import asyncio
from starlette.applications import Starlette
from starlette.routing import Route
from starlette.responses import Response
from sse_starlette.sse import EventSourceResponse
import uvicorn, json, uuid
session_id = str(uuid.uuid4())
async def handle_mcp(request):
if request.method == "POST":
body = await request.json()
method = body.get("method")
if method == "initialize":
resp = {
"jsonrpc": "2.0",
"id": body["id"],
"result": {
"protocolVersion": "2025-06-18",
"capabilities": {"tools": {}},
"serverInfo": {"name": "drop-server", "version": "0.1.0"},
},
}
return Response(
json.dumps(resp),
media_type="application/json",
headers={"mcp-session-id": session_id},
)
if method == "notifications/initialized":
return Response(status_code=202, headers={"mcp-session-id": session_id})
if method == "tools/call":
# Return SSE that sends a priming event with an ID, then drops
async def event_generator():
yield {"event": "message", "id": "evt-1", "data": ""}
# Close without sending the actual response
return
return EventSourceResponse(
event_generator(),
headers={"mcp-session-id": session_id},
)
return Response(status_code=404)
if request.method == "GET":
# GET stream for server-initiated messages — also drop immediately
async def get_stream():
yield {"event": "message", "id": "evt-get-1", "data": ""}
return
return EventSourceResponse(
get_stream(),
headers={"mcp-session-id": session_id},
)
if request.method == "DELETE":
return Response(status_code=200)
app = Starlette(routes=[Route("/mcp", handle_mcp, methods=["POST", "GET", "DELETE"])])
if __name__ == "__main__":
uvicorn.run(app, host="0.0.0.0", port=9999)
Client (client.py): Connects and calls a tool, demonstrating the infinite loop.
"""Client that demonstrates infinite reconnection loop."""
import asyncio, logging
logging.basicConfig(level=logging.INFO)
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client
async def main():
async with streamable_http_client("http://localhost:9999/mcp") as (read, write, _):
async with ClientSession(read, write) as session:
await session.initialize()
print("Initialized. Calling tool (will hang forever)...")
# This call will trigger _handle_reconnection with attempt=0 reset
try:
result = await asyncio.wait_for(
session.call_tool("any_tool", {}),
timeout=30,
)
except asyncio.TimeoutError:
print("CONFIRMED: call_tool hung for 30s (infinite reconnect loop)")
asyncio.run(main())
Steps
pip install mcp[cli] sse-starlette uvicorn- Run server:
python server.py - Run client:
python client.py - Observe: client logs show repeated
"GET stream disconnected, reconnecting in 1000ms..."messages. Thecall_toolnever returns. After 30s thewait_fortimeout fires, confirming the hang.
Root Cause
In streamable_http.py, _handle_reconnection (line 437):
async def _handle_reconnection(self, ctx, last_event_id, retry_interval_ms, attempt=0):
if attempt >= MAX_RECONNECTION_ATTEMPTS: # Only 2
return
# ... reconnects, iterates SSE ...
# Line 494: Stream ended without response — resets attempt to 0!
await self._handle_reconnection(ctx, reconnect_last_event_id, reconnect_retry_ms, 0)
When the reconnection succeeds (HTTP 200) but the stream ends without a complete JSONRPCResponse, line 494 recurses with attempt=0, restarting the counter. Only the exception path (line 498) increments the counter. A server that accepts connections but drops streams causes infinite recursion at 1-second intervals.
Expected Behavior
After MAX_RECONNECTION_ATTEMPTS total reconnection attempts (regardless of whether they succeeded at the HTTP level), the client should give up and propagate an error to the caller.
Suggested Fix
Track total attempts across the recursion rather than resetting on successful connect:
# Line 494: increment instead of reset
await self._handle_reconnection(ctx, reconnect_last_event_id, reconnect_retry_ms, attempt + 1)
Or add a separate max_total_reconnection_attempts counter that is never reset.
Impact
In production, this causes MCP client coroutines to hang forever when a server experiences transient stream drops. The calling application has no way to recover without wrapping every MCP call in asyncio.wait_for(). We discovered this when an agentquant research job hung for 5+ hours in a reconnection loop after an MCP server's SSE stream dropped.
- Vorherrschende Sprache
- Python
- Sterne
- 24.3k
- Forks
- 4k
- Ø Merge
- 1 T. 19 Min.
- Gemergte PRs (30 T.)
- 29
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus modelcontextprotocol/python-sdk
-
v1 v2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
modelcontextprotocol/python-sdk#3546 · 5 Kommentare ·
-
v1 v2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
modelcontextprotocol/python-sdk#3545 · 1 Kommentar ·
-
v1 v2
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 91/100
modelcontextprotocol/python-sdk#3508 · 2 Kommentare ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
modelcontextprotocol/python-sdk#3504 ·
-
v1 v2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
modelcontextprotocol/python-sdk#3492 · 1 Kommentar ·
Alle Issues in modelcontextprotocol/python-sdk
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
-
🐛 Bug 🔔 Pending processing
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
jumpserver/jumpserver#17584 ·