[sentry-junior]

Moves the CLI's request loop out of packages/cli/src/lib/sentry-client.ts and into a new Workers-safe module, @sentry/toolkit-core/api-transport, then switches the CLI over to it. This covers tasks 5.1 and 5.2 of #1669 (unify-sentry-api-layer). It builds on the shared retry policy from #1710.

What's now shared

createApiTransport returns a fetch-shaped request() that owns:

• Auth: it sets the Authorization header from an injected CredentialProvider. The provider supplies the current credential, an optional refresh before expiry, and the refresh after a 401. A 401 refreshes once and replays the request for any method.
• Retries through api-retry. A 429 retries for any method. A 500/502/503/504, a timeout, or a network error retries only for GET/HEAD/OPTIONS, or when the request is marked idempotent. Waits follow Retry-After or X-Sentry-Rate-Limit-Reset, under the caller's caps.
• Per-attempt timeouts: a fixed value or a function of the URL, so the CLI keeps ENDPOINT_TIMEOUT_OVERRIDES.
• Body replay on every attempt, stream bodies included, plus an optional buffered-body mode (auto / buffer / stream). In buffer mode, a body that fails mid-read can still be retried.
• Validated redirects: it follows redirects by hand, sends the credential only to origins the host trusts, and records where the response came from (getValidatedResponseSource).
• Cache port (TransportCache): it looks up GETs, revalidates stale entries with their ETag, stores successful GETs, and invalidates entries after a successful write.

The host plugs in header rules (which may reject a request), its error classes for timeouts, rate limits, and fatal fetch errors (such as TLS failures), a logger, and a span hook. The module uses no Node APIs.

CLI wiring

sentry-client.ts now just configures the transport. It passes in its stored credentials and refresh logic, its host-scope and claim checks (prepareHeaders), the custom TLS fetch, the disk response cache, its tracing span, and its existing error classes. It keeps RETRY_POLICY, ENDPOINT_TIMEOUT_OVERRIDES, and the x-sentry-cli-retry marker. getResponseRequestOrigin and getResponseCredentialIdentity now read the transport's provenance. fetch-input.ts re-exports extractInputUrl from the shared module.

Behavior changes

The goal is the same CLI behavior. One intentional difference:

• An unused response body (one dropped before a retry, a refresh, or a redirect hop) is now cancelled without awaiting the cancel. When a stream is teed, cancelling one branch only settles after the other branch is read. Interceptors such as MSW hand out teed streams, so the old awaited cancel could hang a retry indefinitely. A regression test covers this.

Stacking (#1669)

• Done: 5.0 shared retry policy (fix(mcp): Retry rate-limited GETs using Sentry rate-limit reset headers #1673, ref(cli): Use the shared api-retry policy #1710).
• This PR: 5.1 shared transport and 5.2 the CLI switch.
• Next, stacked on this branch and opened after it merges:
  • 5.3: a request-scoped fresh-read bypass.
  • 6.1: fetch injection for the MCP. SentryApiService drops its own retry loop so retries don't stack.

The OpenSpec tasks file is unchanged here.

Verification

• toolkit-core: 21 files, 269 tests pass, including the new api-transport.test.ts. It covers the retry scenarios, 401 refresh, timeouts, fatal errors, header rules, redirects, the cache, and the teed-body regression.
• CLI unit tests: 11,735 pass. 6 fail, and those same 6 fail on clean main in this sandbox (file-permission tests in completions, telemetry, upgrade, code-scanner, file-changes).
• tsc --noEmit passes for toolkit-core and cli. oxlint, oxfmt --check, and ast-grep scan are clean on the changed paths.

via BYK.

--

View Junior Session in Sentry

[vercel]

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

Project	Deployment	Actions	Updated
sentry-local	Ready	Preview	Oct 29, 2026 12:00pm UTC

[sentry-warden]

401 credential refresh consumes api-retry attempt budget

A 401 refresh is gated on attempt < retry.maxRetries and reuses the same attempt counter as transient retries, so an expired-token refresh leaves one fewer 5xx/timeout retry and starts backoff at the next step. Gate refresh only on !refreshed and keep that replay out of the retry budget.

Evidence

• api-retry.ts states a 401 credential refresh is not a retry; the transport may replay once because the endpoint never ran.
• onResponse only refreshes when attempt < retry.maxRetries, then returns { action: "retry", delayMs: 0 }, which advances the shared for (let attempt = 0; ; attempt++) loop.
• nextRetryDelayMs still uses that incremented attempt for both the remaining retry count (attempt >= maxRetries) and backoff (baseDelayMs * 2 ** attempt).
• With the CLI/MCP default maxRetries: 2, 401 → 503 → 503 fails after refresh, while 503 → 503 → 200 would succeed without the 401.

_{Identified by Warden · code-review · TTN-XGY}