You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cannot break out of session.initialize() when using streamable-http #874
When I use streaming-http connection, I can't jump out of the session initialization. However, when I debug, I find that the initialization request has been sent and the message from the other party has been received, but I can't jump out of initialize.
I'm going to guess this could be for a variety of reasons, so posting some of your related code might be helpful. I confronted something similar today.
When you create a ClientSession and call initialize(), it sends the request successfully (which you can see in your debugging), but then hangs forever waiting for the response. This could happen because the _receive_loop task, which is responsible for reading responses from the stream and routing them to the appropriate handlers, never starts.
Make sure you're entering the session as a context manager:
# This will hang:session=ClientSession(read_stream, write_stream)
awaitsession.initialize() # Hangs forever# This works:session=ClientSession(read_stream, write_stream)
awaitsession.__aenter__() # Starts the receive loopawaitsession.initialize() # Now completes successfully
Or better yet, use it as a proper context manager:
asyncwithClientSession(read_stream, write_stream) assession:
awaitsession.initialize()
# ... use the session
You can try adding logging to _receive_loop to confirm it's starting:
# find `BaseSession` in mcp/shared/session.pyasyncdef_receive_loop(self) ->None:
print("Starting receive loop") # Add thisasyncwith (self._read_stream, self._write_stream):
asyncformessageinself._read_stream:
print(f"Received message: {message}") # And this# ... et cetra
Hope this helps! I spent quite a while debugging this exact issue myself.
Thanks for the report. The v2 rework changed the code this targets, so it no longer applies as-is. I'm closing this out as part of a backlog cleanup now that v2 is out. Feel free to reopen if this is still relevant.
Activity
jonsampson commentedon Jun 6, 2025
I'm going to guess this could be for a variety of reasons, so posting some of your related code might be helpful. I confronted something similar today.
When you create a
ClientSessionand callinitialize(), it sends the request successfully (which you can see in your debugging), but then hangs forever waiting for the response. This could happen because the _receive_loop task, which is responsible for reading responses from the stream and routing them to the appropriate handlers, never starts.Make sure you're entering the session as a context manager:
Or better yet, use it as a proper context manager:
You can try adding logging to _receive_loop to confirm it's starting:
Hope this helps! I spent quite a while debugging this exact issue myself.
zeerd commentedon Sep 12, 2025
I have a same problem.
With the code, it could be run two times, and when it called third time, the
session.initialize()won't return.felixweinberger commentedon Oct 3, 2025
Hi thanks for reporting this! Could you provide a snippet or example code that we can run to debug the specific problem you're facing?
zeerd commentedon Oct 9, 2025
I can not give a simple sample code , but I've already found something.
The case of mine(maybe not as same as the others) is :
MCP Client Bwithin anotherMCP Server A, when theMCP Client Agone.asynciowho throw-ed aasyncio.exceptions.CancelledError:Cancelled by cancel scope xxxxxxCancelledErroris aBaseExceptionwhich could not be caught by normaltry...exceptand the code blocked.felixweinberger commentedon Oct 9, 2025
Reading through here more deeply looks like it might be related to #301
maxisbey commentedon Aug 10, 2026
Thanks for the report. The v2 rework changed the code this targets, so it no longer applies as-is. I'm closing this out as part of a backlog cleanup now that v2 is out. Feel free to reopen if this is still relevant.
AI Disclaimer