Skip to content

fix: prevent sequential Streamable HTTP clients from failing with Already connected to a transport#338

Open
AdaTest wants to merge 4 commits intohangwin:masterfrom
AdaTest:fix/http-mcp-transport-reuse
Open

fix: prevent sequential Streamable HTTP clients from failing with Already connected to a transport#338
AdaTest wants to merge 4 commits intohangwin:masterfrom
AdaTest:fix/http-mcp-transport-reuse

Conversation

@AdaTest
Copy link
Copy Markdown

@AdaTest AdaTest commented May 2, 2026

Summary

  • create a fresh MCP Server for each SSE/Streamable HTTP transport instead of reusing a singleton
  • close the per-transport server when the transport closes
  • prevent sequential Streamable HTTP clients from failing with Already connected to a transport

Verification

  • pnpm --filter mcp-chrome-bridge lint
  • pnpm --filter chrome-mcp-shared build
  • pnpm --filter mcp-chrome-bridge build
  • local repro before the fix: first initialize succeeded, second failed with Already connected to a transport
  • local repro after the fix: first/second/third initializes all succeeded and listed 27 tools

AdaTest added 4 commits May 2, 2026 10:48
Create a fresh MCP Server instance per transport so sequential HTTP/SSE clients do not hit the SDK's already-connected guard.
Keep each per-transport server lifecycle tied to its connection and clean it up when the transport is closed.
Replace the web-edited file with the clean local patch after verifying the editor document length.
Remove the singleton MCP server so each transport can connect to a fresh server instance.
@AdaTest AdaTest changed the title fix: avoid reusing MCP server across transports fix: prevent sequential Streamable HTTP clients from failing with Already connected to a transport May 2, 2026
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.

1 participant