Skip to content

Conversation

@cliffhall
Copy link
Member

Description

  • In sse.ts

    • remove global server, cleanup, and transport vars
    • add transports map
    • in sse GET handler,
      • check for sessionId, there shouldn't be one, so comment "Reconnecting?" and do nothing if present
      • if sessionId not present
        • create new server and transport instance
        • connect server to transport
        • add transport to transports map
        • in server.onclose, delete the transport from the transports map and call cleanup
    • in /message POST handler
      • get the sessionId from the request
      • get the transport from the map by sessionId
      • handle the message if the transport was found
  • In streamableHttp.ts

    • remove the global server and cleanup vars
    • change transports var to Map
    • in /mcp POST handler
      • when creating a new session
        • create a server instance
        • in server.onclose, delete the transport from the transports map and call cleanup
    • remove the calls to cleanup and server.close in the SIGINT handler, because the transport is closed and its onclose handler closes the server.

Server Details

  • Server: everything
  • Changes to: connection behavior

Motivation and Context

Allow multiple connections to the everything server.

For both sse and streamableHttp, a server instance needs to be created for each transport. Otherwise, when a new client connects and its new transport is connected to the single server, the previous transport is overwritten in the server instance and can no longer communicate.

How Has This Been Tested?

Using this Inspector PR which fixes the connection behavior of its proxy server.

Here is a video where I demonstrate the problem with the current version of the server, and then with the fixed versions of the SSE and StreamableHttp servers. Manually tested that STDIO works as well.

Breaking Changes

Nope.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Protocol Documentation
  • My changes follows MCP security best practices
  • I have updated the server's README accordingly
  • I have tested this with an LLM client
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have documented all environment variables and configuration options

Additional context

cliffhall added 2 commits May 22, 2025 11:41
For both sse and streamableHttp, a server instance needs to be created for each transport. Otherwise, when a new client connects and its new transport is connected to the single server, the previous transport is overwritten in the server instance and can no longer communicate.

* In sse.ts
  - remove global server, cleanup, and transport vars
  - add transports map
  - in sse GET handler,
    - check for sessionId, there shouldn't be one, so comment "Reconnecting?" and do nothing if present
    - if sessionId not present
      - create new server and transport instance
      - connect server to transport
      - add transport to transports map
      - in server.onclose, delete the transport from the transports map and call cleanup
  - in /message POST handler
    - get the sessionId from the request
    - get the transport from the map by sessionId
    - handle the message if the transport was found

* In streamableHttp.ts
  - remove the global server and cleanup vars
  - change transports var to Map
  - in /mcp POST handler
    - when creating a new session
      - create a server instance
      - in server.onclose, delete the transport from the transports map and call cleanup
  - remove the calls to cleanup and server.close in the SIGINT handler, because the transport is closed and its onclose handler closes the server.
cliffhall added 3 commits May 28, 2025 11:14
…ive.

 In the first case (line 16) we already know that req.query.sessionId is set to something. I

 n the second (line 40), it doesn't matter because if it doesn't map to a transport no further action is taken.
olaservo
olaservo previously approved these changes May 28, 2025
Copy link
Member

@olaservo olaservo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had one more logging question/suggestion but otherwise looks good to me.

…sessionId, output a "No transport found for sessionId" message.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants