Repository navigation
bug(client/streamable_http): prevent infinite SSE reconnect loops with bounded exponential backoff #3356
Description
Activity
I can reproduce the reconnect-loop behavior described here. I’d be interested in working on a focused fix that keeps the reconnection attempt count bounded across SSE disconnects, applies the existing backoff behavior, and adds regression coverage for repeated disconnects. Happy to work on this if the approach aligns with what you have in mind.
I think this is the same bug as #3257. In
handle_get_stream(src/mcp/client/streamable_http.py, around L252-253 on main and L310-311 on v1.x), a GET stream that ends without an exception setsattempt = 0. So a server that keeps closing the stream cleanly never pushes the counter towardMAX_RECONNECTION_ATTEMPTS, and the client reconnects forever. #3087 (currently a draft) already targets this by not resetting the counter on empty connections, so it may be worth tracking or reviewing that PR rather than opening a separate fix. @jagadeepmamidi, if you want to help, the regression test you described would probably be a useful addition there.
Problem
In
StreamableHTTPTransport.handle_get_stream, when an SSE stream disconnects or closes (server-side EOF/backpressure),attemptwas reset to 0 upon exit. If an upstream server disconnects continuously, the client bypassesMAX_RECONNECTION_ATTEMPTSand enters an infinite reconnection loop without backoff jitter.Expected Behavior
The client should respect
MAX_RECONNECTION_ATTEMPTSon stream disconnects and apply exponential backoff to prevent thundering-herd storms on upstream MCP servers.