Skip to content

fix: surface failed request forwards as JSON-RPC errors instead of hanging - #308

Open
SvenJuergens wants to merge 1 commit into
geelen:mainfrom
SvenJuergens:fix/surface-forward-errors
Open

fix: surface failed request forwards as JSON-RPC errors instead of hanging#308
SvenJuergens wants to merge 1 commit into
geelen:mainfrom
SvenJuergens:fix/surface-forward-errors

Conversation

@SvenJuergens

Copy link
Copy Markdown

Problem

Fixes the "hang" part of #106.

When transportToServer.send() rejects while forwarding a client request, the error is only logged:

transportToServer.send(message).catch(onServerError)

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-Id unknown), mcp-remote logged Error 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 in interceptRequest. Hosts then fail fast and can reconnect. Failed notifications (no id) 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 --check and tsc are clean.

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.
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