[sentry-junior]

The hosted MCP gets rate limited by the Sentry API a lot. In the last 7 days sentry/mcp-server logged about 32.6K http.client 429s, nearly all on GETs, usually "Limit is 40 requests in 1 seconds", plus about 72 concurrency-limit hits. SentryApiService.request() only retried 502/503/504, so every 429 failed the tool call. ApiRateLimitError.retryAfter was read from body fields Sentry never sends, so nothing could say when to try again.

Sentry's 429 body is just {"detail": ...}. The timing comes in headers set by src/sentry/middleware/ratelimit.py: X-Sentry-Rate-Limit-Reset is the Unix second when the next window starts, and Remaining is 0 only when the fixed window is used up. Concurrency 429s carry a reset that doesn't apply to them.

This adds @sentry/toolkit-core/api-retry, a pure retry policy with no Node APIs, so it is safe on Workers. It is task 5.0 in #1669. The MCP adopts it here:

• What gets retried: GET and HEAD requests that get a 429 or a 502/503/504. Writes are never retried. The policy's idempotent opt-in exists for the CLI's content-addressed uploads, but the MCP doesn't use it.
• How long a 429 waits: until Retry-After (seconds or HTTP-date) if a proxy sent one, otherwise until X-Sentry-Rate-Limit-Reset. The reset is measured against the response Date when the local clock is off by more than 2s, plus a small jitter. Concurrency 429s and gateway errors use equal-jitter exponential backoff starting at 250ms.
• Caps: at most 2 retries, 2s per wait and 3s in total. Sentry's windows are mostly 1s, so the reset is usually under a second away and both retries fit in about 2s. A reset further out than 2s means a longer window. Then the call fails at once instead of holding the Worker request open. The error is an ApiRateLimitError with a real retryAfterMs, and its message ends with "Retry in N seconds." When there is no header, it says to wait a few seconds and make fewer parallel requests.
• Abort: aborting the request's signal ends the wait immediately.

ApiRateLimitError.retryAfter (seconds, from the body) is replaced by retryAfterMs, taken from the headers. Nothing read the old field.

The CLI currently has its own interim retry fix in a separate CLI-only PR. It moves onto this shared module in a follow-up after that PR lands. Once the MCP is on the shared transport (#1669 task 6.1), SentryApiService drops this loop so retries don't stack.

via @BYK.

--

View Junior Session [Sentry]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
sentry-local	Ready	Preview	Oct 27, 2026 3:30pm UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a4f9a98. Configure here.}

[BYK]

We should then abstract this logic out either into toolkit-core or @sentry/api (ideally) and make it shared across CLI and MCP

[BYK]

We should link this information to the code or from the code. Ideally the code should have something like:

const RETRIABLES = {
  429: true,
  500: ["GET", "HEAD", "OPTIONS"],
};

or other way around:

const RETRIABLES = {
  "GET": [429, 500, 502, 503, 504],
  "POST": [429],
}

etc. Or some rule. Also ideally these will be Map and Set instances yadda yadda.

[sentry-junior]

Done in abc41b8. packages/toolkit-core/src/api-retry.ts now has RETRYABLE_STATUSES: ReadonlyMap<number, "any" | "idempotent">, which maps 429 to any and 500/502/503/504 to idempotent. IDEMPOTENT_METHODS is a ReadonlySet. The any/idempotent rationale lives on the map. RetryPolicy lost retryableStatuses, so a product only sets caps and can't drift from the rule. This doc section now shows the same table and links to the file, and the code comment points back here.

[sentry-junior]

On sharing this between CLI and MCP: the rule now lives only in @sentry/toolkit-core/api-retry, as the RETRYABLE_STATUSES map, the header parsing, and nextRetryDelayMs/sleep. The MCP supplies just its caps (abc41b8).

I haven't switched the CLI in this PR. #1677 (fix/cli-retry-idempotent-429) is open and rewrites the same retry code in packages/cli/src/lib/sentry-client.ts, so touching it here would conflict. The CLI moves onto this module in a follow-up once #1677 lands. That's task 5.0's "CLI follow-up" in #1669, and 5.1 then moves the whole transport.

@sentry/api is the better long-term home, and #1669 already lists "move pagination, then the transport, into @sentry/api" as a follow-up. I kept it in toolkit-core for now so this fix doesn't wait on an @sentry/api release.