claude-code - 💡(How to fix) Fix [BUG] Streamable HTTP MCP: in-flight tool call Promise orphaned forever on connection drop [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55992Fetched 2026-05-05 06:00:59
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

Error Message

09:50:02 — Tool 'workspace_load' dispatched 09:50:04 — HTTP connection dropped after 2820s uptime 09:50:04 — Connection error: Received a response for an unknown message ID (server's -32010 error for dead session) 09:50:32 — Tool 'workspace_load' still running (30s elapsed) 09:50:41 — user-cancel after 38s (only way to recover)

Root Cause

The MCP SDK's StreamableHTTPClientTransport detects the connection drop but doesn't:

  1. Reject Promises for requests that were in-flight on the old connection
  2. Automatically trigger reconnection after the drop

The timeoutMs: 60000 option only applies to connection setup, not to individual tool calls. There is no per-request timeout.

Fix Action

Fix / Workaround

09:50:02 — Tool 'workspace_load' dispatched
09:50:04 — HTTP connection dropped after 2820s uptime
09:50:04 — Connection error: Received a response for an unknown message ID (server's -32010 error for dead session)
09:50:32 — Tool 'workspace_load' still running (30s elapsed)
09:50:41 — user-cancel after 38s (only way to recover)

Code Example

09:50:02Tool 'workspace_load' dispatched
09:50:04HTTP connection dropped after 2820s uptime
09:50:04Connection error: Received a response for an unknown message ID (server's -32010 error for dead session)
09:50:32Tool 'workspace_load' still running (30s elapsed)
09:50:41 — user-cancel after 38s (only way to recover)

---

09:57:59User triggers /mcp reconnect (settings.local.json change detected)
09:59:45"HTTP transport closed/disconnected, attempting automatic reconnection"
09:59:48"HTTP reconnection successful after 3182ms (attempt 1)"
09:59:53 — workspace_load succeeds in 17s
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

When an HTTP SSE connection to a Streamable HTTP MCP server drops while a tool call is in-flight, the pending Promise is never resolved or rejected. The tool hangs indefinitely until the user manually cancels (Escape). The connection remains broken afterward — the user must manually reconnect via /mcp for subsequent calls to work.

Steps to Reproduce

  1. Configure a Streamable HTTP MCP server (e.g., hosted on AWS Bedrock AgentCore)
  2. Use it normally for 30+ minutes (long enough for a server-side session timeout or network blip)
  3. Trigger a tool call right as the HTTP connection drops (or force a drop by restarting the server)
  4. The tool call hangs indefinitely with "still running (30s elapsed)..." messages
  5. Only recovery: press Escape to cancel, then manually run /mcp to reconnect

Expected Behavior

When the HTTP SSE connection drops, all pending request Promises should be immediately rejected with an error (e.g., "connection lost"), and the client should automatically reconnect for subsequent calls.

Actual Behavior

09:50:02 — Tool 'workspace_load' dispatched
09:50:04 — HTTP connection dropped after 2820s uptime
09:50:04 — Connection error: Received a response for an unknown message ID (server's -32010 error for dead session)
09:50:32 — Tool 'workspace_load' still running (30s elapsed)
09:50:41 — user-cancel after 38s (only way to recover)

After cancel, the connection remains broken. User must manually /mcp reconnect (~9 min later in this case):

09:57:59 — User triggers /mcp reconnect (settings.local.json change detected)
09:59:45 — "HTTP transport closed/disconnected, attempting automatic reconnection"
09:59:48 — "HTTP reconnection successful after 3182ms (attempt 1)"
09:59:53 — workspace_load succeeds in 17s

Once reconnected, everything works normally (subsequent calls: 5s, 1s, 12s).

Root Cause

The MCP SDK's StreamableHTTPClientTransport detects the connection drop but doesn't:

  1. Reject Promises for requests that were in-flight on the old connection
  2. Automatically trigger reconnection after the drop

The timeoutMs: 60000 option only applies to connection setup, not to individual tool calls. There is no per-request timeout.

Proposed Fix

  1. When the HTTP connection drops (SSE stream closes), immediately reject all pending request Promises with a connection error
  2. Automatically trigger reconnection after a connection drop (don't wait for user to run /mcp)
  3. Optionally, expose a configurable per-tool-call timeout (e.g., MCP_TOOL_TIMEOUT) that races each callTool with a deadline

Related Issues

  • #43342 — Plugin MCP tools hang indefinitely with no timeout or error
  • #47076 — Make MCP tool call timeout configurable (MCP_TOOL_TIMEOUT)
  • #27142 — Streamable HTTP client does not re-initialize after session invalidation
  • #15758 — MCP tools silently disappear mid-session
  • #36308 — MCP servers should auto-reconnect when disconnected

Environment Info

  • Platform: darwin (macOS)
  • Version: 2.1.126
  • Transport: Streamable HTTP ("type": "http")
  • MCP server: Custom server on AWS Bedrock AgentCore Runtime

extent analysis

TL;DR

The proposed fix involves immediately rejecting pending request Promises with a connection error and automatically triggering reconnection after an HTTP connection drop.

Guidance

  • Review the StreamableHTTPClientTransport implementation to ensure it correctly handles connection drops and rejects in-flight Promises.
  • Consider adding a configurable per-tool-call timeout (MCP_TOOL_TIMEOUT) to provide a deadline for each callTool request.
  • Verify that the reconnection mechanism is properly triggered after a connection drop, without requiring user intervention.
  • Investigate related issues (#43342, #47076, #27142, #15758, #36308) for potential connections to this problem.

Example

No code snippet is provided, as the issue description does not include specific code references.

Notes

The proposed fix assumes that the StreamableHTTPClientTransport implementation can be modified to handle connection drops and reject pending Promises. Additionally, the introduction of a per-tool-call timeout may require careful consideration of its default value and potential impact on tool behavior.

Recommendation

Apply the proposed fix, which involves modifying the StreamableHTTPClientTransport to reject pending Promises and trigger reconnection after a connection drop, as this addresses the root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Streamable HTTP MCP: in-flight tool call Promise orphaned forever on connection drop [1 comments, 2 participants]