GeezerVison

…ilures

A 429 or 503 token answer now records its Retry-After (delay-seconds or
HTTP-date, RFC 9110 section 10.2.3) as an optional retryAfterMs on
TokenServiceAccountValidationError, through throwForProviderResponse and the
shared client-credentials grant, whose provider classifier receives it.

…h outages

The per-instance client-credential mint cache now:
- serves a cached token that is inside its five-minute early-refresh window
  but not expired when the refresh fails with an outage or throttling, as
  MSAL, Azure.Core and botocore do; a refusal of the credentials still fails
- retries a quick transient mint failure once after about a second
- replays failures by kind instead of a flat 30 s: a refusal 30 s, a
  throttled answer for its Retry-After (1 s to 5 min), an outage 5 s growing
  to 30 s while it continues

The policy lives in lib/credentials/token-request-resilience.ts so the
coordinated resolver can share it.

…he coordinated resolver

The coordinated client-credentials resolver (Shopify, Linear, Atlassian,
Vanta) now applies the same policy as the per-instance mint cache, through
the shared row every worker reads:
- a quick outage is retried once under the application lock, within the 15 s
  its waiters allow
- a refusal is remembered 30 s, a throttled answer for its Retry-After (1 s to
  5 min, Vanta's now included), an outage 5 s growing to 30 s while it lasts
- while an outage or throttling is remembered, the stored token for the same
  secret is served until 30 s before it expires; a refusal fails at once

Rolling deploys stay safe: a refusal is stored exactly as before, and outages
add only a consecutiveFailures key that previous decoders ignore (both prior
decoders are pinned in the integration tests). The replay length rides on the
row's existing expiresAt. Expired memos are kept five more minutes so the next
failure can extend the backoff; an older build's sweep only resets it.

…emembered failures without the lock

- A 429 that names no Retry-After is replayed for at least a minute, doubling
  up to the five-minute cap, instead of the 5 s outage curve.
- The outage backoff never undercuts Entra's 5 s first-retry floor through jitter.
- Vanta asks for a token at most once per 15 s while exchanges fail (no
  in-request retry, replay floored), within its documented 5 tokens a minute,
  through a new optional minExchangeIntervalMs on the coordinated resolver.
- A remembered failure and the still-valid fallback are served from committed
  rows before the application lock is taken, so a refresh outage no longer
  serializes every resolution behind the lock.
- retryAfterMs now only carries a provider's Retry-After; a replayed memo
  reports its remainder as the additive replayForMs, which the per-instance
  layer honors exactly.
- One decode/verify path for stored tokens; the stored-failure permanence
  check uses isPermanentTokenFailureCode instead of building an error.

…llback gaps

- Carry the token endpoint's Retry-After on 429/503 failures from every
  bespoke client-credential minter (Box, Zoom, DocuSign, NetSuite, Help
  Scout, Ramp, Jama, Zendesk, Salesforce, Zoho Desk) and through the
  CrowdStrike, SailPoint and ZoomInfo client errors, so their throttled
  answers wait as long as the provider asks instead of the fixed backoff.
- Recheck the 30 s expiry margin when the per-instance cache falls back
  to a still-valid token after a slow failed refresh.
- Map an unreadable Vanta token body to provider_unavailable so it is
  remembered for every worker and paced at 15 s like any failed exchange.
- Remember a refusal whose code the shared failure row cannot store with
  an additive `refusal` flag, so a replay never serves the stale token.
- Rename the credentials helper to throttledRetryAfterMs so it no longer
  shares a name with providers/retry.ts.

…d redact the fallback log in selector mode

cubic-dev-ai Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

…ls, and keep throttle delays through SailPoint and CrowdStrike

- A refusal of the credentials drops the per-instance cached token and expires the shared
  token minted with that secret, so a later outage cannot serve it again.
- A previous build's provider_unavailable memo with a non-transient 4xx status replays as a
  refusal instead of serving the stored token.
- The SailPoint saved-credential minter returns the first 429 with its Retry-After instead of
  retrying until the exchange timeout swallows it.
- A CrowdStrike error whose body cannot be read keeps its status and Retry-After.
- Vanta logs a malformed or oversized token response apart from an unreadable stream.

cubic-dev-ai Bot left a comment