auth token expired mid-run: agent's deploy retries burned the remaining rate limit, deploy failed

TL;DR: Classify the error before retrying: 401/403 means stop and re-authenticate, 429 means back off, and never the same loop for both. Each failed-auth request still counts against the rate budget, so retrying a deploy with a dead credential converts one problem into two - dead credential plus exhausted budget. Kill the retry loop, get a fresh credential, verify it, wait out the rate window, then deploy exactly once.

auth token expired mid-run: agent's deploy retries burned the remaining rate limit, deploy failed

Steps

1. Kill the retry loop immediately. Sort the log's errors by status code. Expected: you see 401s (auth) turning into 429s (rate limit) - the signature of this compound failure.
2. Re-authenticate with a fresh credential and verify with wrangler whoami. Expected: correct account, no auth error. Do this before any further deploy attempt.
3. Check what's live: wrangler deployments list. Expected: you know whether any retry partially landed before the budget ran out.
4. Wait for the rate-limit window to clear - a few minutes, honoring Retry-After. Expected: the next mutating call doesn't 429.
5. Deploy exactly once with the fresh credential. Expected: success, and the live version matches this deploy.
6. Fix the retry policy for good: 401/403 triggers re-auth then a single retry; 429 triggers backoff with the checkpoint saved; 5xx gets a small bounded retry count. Expected: no single retry loop ever handles all three the same way again.

Use this when

• deploy logs show auth errors followed by rate-limit errors in one run
• "retries burned the rate limit" or the budget died during a retry storm
• the credential expired and the agent kept retrying instead of re-authenticating
• any compound auth-plus-rate-limit failure

Not for this skill when

• it's pure rate limiting with a valid credential - just back off, no re-auth needed
• it's pure auth failure with no retries yet - re-authenticate, nothing burned
• the 403s are permission errors, not expiry - re-auth won't fix scope
• the deploy never started - there's nothing compound about it

Variant phrasings

• deploy retries with an expired credential caused 429s
• auth failure plus rate limit exceeded in one run
• agent kept retrying deploy with dead credentials
• 401s turned into 429s during deploy retries

Why it happens

Failed-auth requests still consume rate-limit budget, so a naive retry loop spends the budget on requests that could never succeed. By the time anything notices the credential is dead, there are two failures to recover from instead of one - and the recovery order matters: fresh credential first, then wait out the budget.

Edge cases

• Some 403s mean "wrong permissions", not "expired". Read the message: re-auth fixes expiry, not scope.
• The rate-limit window is shared account-wide. Other automation running concurrently extends the wait.
• If a retry did partially land, the deployments list shows it. Don't assume all retries failed.
• Long-lived service credentials avoid the expiry half of this failure for scheduled runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_V0rxR73vXQM7v8z8k0gwsw