Title: fix(mcp): keep the pooled connection warm on a request timeout by waleedlatif1 · Pull Request #5817 · simstudioai/sim · GitHub
Open Graph Title: fix(mcp): keep the pooled connection warm on a request timeout by waleedlatif1 · Pull Request #5817 · simstudioai/sim
X Title: fix(mcp): keep the pooled connection warm on a request timeout by waleedlatif1 · Pull Request #5817 · simstudioai/sim
Description: Summary Empirically diagnosed (2h of staging logs + an A/B test), not guessed: The server is fast. A normal client (curl, HTTP/1.1 and HTTP/2, no IP pin) does MCP initialize to these servers in ~120 ms every time, first attempt included. Our client's first connect consistently hangs to our 30s timeout, then the retry connects in ~100 ms — 6/6 in the logs. So it's a client-side first-connect stall, not server flakiness. The killer: isDeadConnectionError treated a request timeout as a dead connection, so one tools/list timeout retired the whole pooled connection → the next discovery reconnected and paid the first-connect stall again → a connect/stall/reconnect churn loop. This is what produced the intermittent "Failed to discover MCP tools" and disconnected states. Fix Stop poisoning the lease on a request timeout. A streamable-HTTP request timeout aborts only that request's own POST stream; the session stays healthy for the next request. Only a real transport close / 404 (session gone) / socket reset retires the connection now. This matches every production MCP client reviewed (MCP TypeScript SDK, OpenCode, LibreChat) — none retire a connection on a request timeout. Type of Change Bug fix (resilience; removes connection churn) Testing New unit test: a request timeout keeps the pooled connection warm (never poisons the lease). Existing poison tests (404 / auth / reset → still retire) unchanged and green (7/7). Type-check + biome clean. Follow-ups (not in this PR) Reduce tools/list polling cadence (reference clients discover once + refresh on list_changed, not a 30s poll). Investigate the single-IP pin as the first-connect-stall cause (best practice: no client pins IPs) — strong circumstantial evidence but not yet directly reproduced; it touches an SSRF control, so it needs its own proof + careful change. Checklist Code follows project style guidelines Self-reviewed my changes Tests added/updated and passing No new warnings introduced I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)
Open Graph Description: Summary Empirically diagnosed (2h of staging logs + an A/B test), not guessed: The server is fast. A normal client (curl, HTTP/1.1 and HTTP/2, no IP pin) does MCP initialize to these servers in ~1...
X Description: Summary Empirically diagnosed (2h of staging logs + an A/B test), not guessed: The server is fast. A normal client (curl, HTTP/1.1 and HTTP/2, no IP pin) does MCP initialize to these servers in ~1...
Opengraph URL: https://github.com/simstudioai/sim/pull/5817
X: @github
Domain: github.com
| route-pattern | /:user_id/:repository/pull/:id/files(.:format) |
| route-controller | pull_requests |
| route-action | files |
| fetch-nonce | v2:a111dac2-78ba-7a7f-65f1-b86792417ce4 |
| current-catalog-service-hash | ae870bc5e265a340912cde392f23dad3671a0a881730ffdadd82f2f57d81641b |
| request-id | 8F2E:262720:8471AB:BBEAB5:6A637B51 |
| html-safe-nonce | 967b5437ccb0d6b35ef10def21307b833efc92c1f9212693fb7c2cfa769c88be |
| visitor-payload | eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiI4RjJFOjI2MjcyMDo4NDcxQUI6QkJFQUI1OjZBNjM3QjUxIiwidmlzaXRvcl9pZCI6IjQwOTU3NzIwNDg5NDU4MDYxNjEiLCJyZWdpb25fZWRnZSI6ImlhZCIsInJlZ2lvbl9yZW5kZXIiOiJpYWQifQ== |
| visitor-hmac | 7980c06d1daebab217c2a25e0caafb338f0881faca8a9ca8a2a81e66c4f1cdda |
| hovercard-subject-tag | pull_request:4103189900 |
| github-keyboard-shortcuts | repository,pull-request-list,pull-request-conversation,pull-request-files-changed,copilot |
| google-site-verification | Apib7-x98H0j5cPqHWwSMm6dNU4GmODRoqxLiDzdx9I |
| octolytics-url | https://collector.github.com/github/collect |
| analytics-location | / |
| fb:app_id | 1401488693436528 |
| apple-itunes-app | app-id=1477376905, app-argument=https://github.com/simstudioai/sim/pull/5817/files |
| twitter:image | https://avatars.githubusercontent.com/u/40672544?s=400&v=4 |
| twitter:card | summary_large_image |
| og:image | https://avatars.githubusercontent.com/u/40672544?s=400&v=4 |
| og:image:alt | Summary Empirically diagnosed (2h of staging logs + an A/B test), not guessed: The server is fast. A normal client (curl, HTTP/1.1 and HTTP/2, no IP pin) does MCP initialize to these servers in ~1... |
| og:site_name | GitHub |
| og:type | object |
| hostname | github.com |
| expected-hostname | github.com |
| None | 4c1de337de00c7969335f8866af41463301071379a3a15fba12e9b85aa6378d6 |
| turbo-cache-control | no-preview |
| diff-view | unified |
| go-import | github.com/simstudioai/sim git https://github.com/simstudioai/sim.git |
| octolytics-dimension-user_id | 199344406 |
| octolytics-dimension-user_login | simstudioai |
| octolytics-dimension-repository_id | 912559512 |
| octolytics-dimension-repository_nwo | simstudioai/sim |
| octolytics-dimension-repository_public | true |
| octolytics-dimension-repository_is_fork | false |
| octolytics-dimension-repository_network_root_id | 912559512 |
| octolytics-dimension-repository_network_root_nwo | simstudioai/sim |
| turbo-body-classes | logged-out env-production page-responsive full-width |
| disable-turbo | true |
| browser-stats-url | https://api.github.com/_private/browser/stats |
| browser-errors-url | https://api.github.com/_private/browser/errors |
| release | a4df32552e4c631011bdcd4c81cc3d7408664a8b |
| ui-target | full |
| theme-color | #1e2327 |
| color-scheme | light dark |
Links:
Viewport: width=device-width