You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(mcp): bound + parallelize provider discovery so one bad provider can't stall the aggregate (#373)
The hub-side federation already skipped providers that errored (EOF/405) and
recovered AddTool panics, so a crashing provider couldn't poison the aggregate
tool list. The remaining gap was a SLOW/HUNG provider: discovery was a sequential
loop with the client's 15s per-request timeout, so one hung provider stalled the
whole tools/list — and serialized every healthy provider behind it.
Fan out per-provider tools/list concurrently, each under a short
providerDiscoveryTimeout (8s, well under the 15s call timeout). A hung provider
now costs at most that one deadline, in parallel, then drops out of this round
and reappears on the next once it recovers. Tools are still registered
sequentially in the original provider order (AddTool isn't guaranteed
goroutine-safe) so the aggregate tool list stays deterministic. Discovery
goroutines also recover panics individually.
Adds a regression test: a healthy provider + a provider whose /mcp hangs; asserts
the healthy provider's tool still registers, the hung one drops out, and the
aggregate builds in well under the client timeout.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments