Skip to content

Cannot break out of session.initialize() when using streamable-http #874

Closed as not planned

Description

@efcwetgw

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.

Activity

  1. jonsampson commented on Jun 6, 2025

    @jonsampson

    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)
    await session.initialize()  # Hangs forever
    
    # This works:
    session = ClientSession(read_stream, write_stream)
    await session.__aenter__()  # Starts the receive loop
    await session.initialize()  # Now completes successfully

    Or better yet, use it as a proper context manager:

    async with ClientSession(read_stream, write_stream) as session:
        await session.initialize()
        # ... use the session

    You can try adding logging to _receive_loop to confirm it's starting:

    # find `BaseSession` in mcp/shared/session.py
    
    async def _receive_loop(self) -> None:
        print("Starting receive loop")  # Add this
        async with (self._read_stream, self._write_stream):
            async for message in self._read_stream:
                print(f"Received message: {message}")  # And this
                # ... et cetra

    Hope this helps! I spent quite a while debugging this exact issue myself.

  2. zeerd commented on Sep 12, 2025

    @zeerd

    I have a same problem.

            async with streamablehttp_client(url=url) as (
                read_stream,
                write_stream,
                _,
            ):
                log.debug('MCPClient.run::streamablehttp_client done', level=4)
                async with ClientSession(
                    read_stream, write_stream,
                    elicitation_callback=elicitation_callback
                ) as session:
                    log.debug('MCPClient.run::ClientSession done', level=4)
                    await session.initialize()
                    log.debug('MCPClient.run::initialize done', level=4)

    With the code, it could be run two times, and when it called third time, the session.initialize() won't return.

  3. added
    needs confirmationNeeds confirmation that the PR is actually required or needed.
    bugSomething isn't working
    on Sep 19, 2025
  4. added
    needs reproneeds additional information to be able to reproduce bug
    and removed
    needs confirmationNeeds confirmation that the PR is actually required or needed.
    on Oct 3, 2025
  5. felixweinberger commented on Oct 3, 2025

    @felixweinberger
    Contributor

    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?

  6. zeerd commented on Oct 9, 2025

    @zeerd

    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 :

    • Creating a MCP Client B within another MCP Server A, when the MCP Client A gone.
    • MCP codes called asyncio who throw-ed a asyncio.exceptions.CancelledError:Cancelled by cancel scope xxxxxx
    • CancelledError is a BaseException which could not be caught by normal try...except and the code blocked.
  7. felixweinberger commented on Oct 9, 2025

    @felixweinberger
    Contributor

    Reading through here more deeply looks like it might be related to #301

  8. added
    ready for workEnough information for someone to start working on
    P1Significant bug affecting many users, highly requested feature
    and removed
    needs reproneeds additional information to be able to reproduce bug
    on Oct 9, 2025
  9. maxisbey commented on Aug 10, 2026

    @maxisbey
    Contributor

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1Significant bug affecting many users, highly requested featurebugSomething isn't workingready for workEnough information for someone to start working on

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions