Repository navigation
MCP connections keep contacting an endpoint during Retry-After after HTTP 429 #52854
Description
Description
OpenCode V2 can contact the same remote MCP endpoint again immediately after an HTTP 429 response, despite the server's Retry-After header. A second connection does not respect the cooldown established by the first connection's rejection.
A generic local server returning HTTP 429 with Retry-After: 60 received two initialization requests from two sequential connection attempts. The second attempt should fail locally during that interval rather than send another request.
The cooldown should apply across connections to that endpoint. This does not require automatic retries, and rejected tool calls should not be queued or replayed.
Plugins
No external plugins are needed for the core regression.
OpenCode version
V2 source checkout.
Steps to reproduce
The executed regression is MCP cooldown suppresses repeated initialization after HTTP 429 in packages/core/test/mcp.test.ts in the proposed fix.
- Start the generic local MCP server that returns HTTP 429 with
Retry-After: 60. - Attempt two sequential connections to the same URL, with OAuth disabled.
- Count requests received by the server.
The unpatched implementation sent two requests instead of one. The regression passed with the endpoint cooldown in place.
Screenshot and/or share link
Not applicable. The regression checks HTTP request counts.
Operating System
macOS.
Terminal
Not applicable. This is a core integration test.
Activity
github-actions commentedon Oct 2, 2026
This issue might be related to existing MCP connection recovery reports. Please check:
These may have different triggers, but they cover related remote MCP connection retry behavior.
opencodejr commentedon Oct 27, 2026
Thanks for the report and for the regression test, @davdroman!
The request, as I understand it: when a remote MCP server replies with HTTP 429 and
Retry-After, OpenCode should keep a cooldown for that endpoint and apply it across connections. New attempts during that window should fail locally instead of sending another request, with no automatic retries and no queued or replayed tool calls.Right now the MCP client deliberately treats 429 as a transient error. It retries twice with short fixed delays (250 ms and then 1 s, from #52614) and doesn't read
Retry-After. So I'm filing this as an improvement rather than a bug. It would match how web search and model calls already handleRetry-After. Maintainers will consider it along with your PR #52855.Related: