fix: surface failed request forwards as JSON-RPC errors instead of hanging - #308
Open
SvenJuergens wants to merge 1 commit into
Open
fix: surface failed request forwards as JSON-RPC errors instead of hanging#308SvenJuergens wants to merge 1 commit into
SvenJuergens wants to merge 1 commit into
Conversation
When forwarding a client request to the remote server fails, the error was only logged. The local client keeps waiting for a response that never arrives and appears to hang forever — e.g. when the server expired the session and answers HTTP 404 (see geelen#106). Send a JSON-RPC error response for the affected request id back to the local client instead, so hosts fail fast and can reconnect. Notifications carry no id and are still not answered.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes the "hang" part of #106.
When
transportToServer.send()rejects while forwarding a client request, the error is only logged:The local client keeps waiting for a response to its request id that will never arrive — from the host's perspective (Claude Code, Cursor, …) the tool call hangs indefinitely. We debugged this in production against a TYPO3 MCP server: the server answered a spec-conform HTTP 404 for an expired session (
Mcp-Session-Idunknown), mcp-remote loggedError POSTing to endpoint (HTTP 404)— and the host waited 30 minutes into its idle timeout.Change
If forwarding a request (message with an
id) fails, send a JSON-RPC error response for that id back to the local client, mirroring the pattern already used for blocked tools ininterceptRequest. Hosts then fail fast and can reconnect. Failed notifications (noid) are still not answered, as JSON-RPC forbids responses to them.This intentionally does not implement the full spec behaviour for 404 ("client MUST start a new session by sending a new InitializeRequest") — that needs replaying the cached initialize params and is better done as a follow-up. Surfacing the error at least turns a silent forever-hang into an actionable failure.
Tests
Two new scenarios in
utils.test.ts(55/55 passing): a rejected request forward produces a JSON-RPC error response with the original id; a rejected notification forward produces no response.prettier --checkandtscare clean.