stacklok / toolhive / 30807652804

70%

Build Type

push

github

Committed by web-flow

Commit Message

Serve repeat initialize from a cached result (#6153)

* Serve repeat initialize from a cached result

A stdio MCP server is one process and therefore exactly one MCP session,
while the streamable proxy fans an arbitrary number of HTTP client
sessions onto it. Every client's initialize was forwarded to that single
session, so only the first could succeed: go-sdk v1.7+ rejects a second
handshake with `duplicate "initialize" received`. Behind vMCP that takes
down far more than the reported health check -- every call verb builds a
fresh client and handshakes, so tool calls fail too once the aggregator
has claimed the one handshake at startup.

Cache the InitializeResult from the first handshake and answer later
ones locally, restoring what go-sdk v1.6.1 and earlier did when it
replayed a repeated initialize, but in the component that actually owns
the multiplexing. The cache lock is held across the first upstream round
trip so concurrent handshakes single-flight instead of racing a second
initialize to the backend; forwardUpstream's timeout bounds it. Errors
are never cached, so a transient failure cannot pin every later client
to one bad response.

Swallow notifications/initialized after the first for the same reason:
the backend completed one handshake and expects one such notification.
Later ones are still acknowledged with 202.

Server capabilities in the replayed result do not vary by client, and
client capabilities are inert here because server-initiated requests are
already rejected by the shared proxy. The negotiated protocol version is
the one genuinely shared value: a client that asked for a different one
receives the first client's.

Closes #1982

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Assert handshakes against a duplicate-rejecting backend

The initialize cache tests used a permissive stub that accepted every
handshake, so they could only count how many messages reached the
backend -- they could never produce the... (continued)

Coverage Stats

47 of 53 new or added lines in 2 files covered. (88.68%)

11 existing lines in 5 files now uncovered.

82742 of 118216 relevant lines covered (69.99%)

97.55 hits per line