• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

stacklok / toolhive / 30807652804

03 Aug 2026 10:58AM UTC coverage: 69.992% (+0.02%) from 69.969%
30807652804

push

github

web-flow
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)

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

Source File
Press 'n' to go to next uncovered line, 'b' for previous

86.05
/pkg/transport/proxy/streamable/initialize_cache.go


Build SHA Not Found

The commit SHA "5fecff44a4a1d6e613937233a8825a6722d41a73" was not found in your repository, so the file cannot be loaded. This may be because you posted from a local development environment, or your CI created an ephemeral commit.

STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc