agent hit a 429 from the npm registry mid-verification and gave up instead of backing off and retrying

TL;DR: Back off and retry on the 429; the registry is asking for patience, not refusing the request. Read the Retry-After hint, wait with exponential backoff and jitter, then resume the verification step where it left off. Giving up on the first 429 turns routine rate limiting into a failed upgrade.

agent hit a 429 from the npm registry mid-verification and gave up instead of backing off

1. Read the Retry-After value from the 429 response.

Expected: the exact wait the registry asks for, no guessing.

1. Wait with exponential backoff plus jitter before the next request.

Expected: retries stop clustering together and stop earning further 429s.

1. Resume the verification step from where it stopped instead of restarting it from scratch.

Expected: completed work is not redone, which means fewer requests overall.

1. Reduce request volume going forward: cache tarballs and metadata between verification runs.

Expected: fewer requests per verification, fewer 429s in the first place.

Use this when

• The npm registry returned 429 during upgrade verification
• The agent gave up on rate limiting with no retry
• "Gave up instead of backing off" describes the agent's behavior
• Verification failed with "too many requests"

Not for this skill when

• The registry returns 403 (an auth problem, not rate limiting)
• The registry returns 5xx errors (different retry policy, usually shorter backoff)
• The 429 came from the GitHub API rather than the npm registry (different quota model)

Variant phrasings

• npm 429 with no backoff
• rate limited, agent gave up verification
• npm registry too many requests, agent quit
• 429 mid-verification with no retry

Why it happens

The agent treated 429 like a permanent failure. Registries rate-limit aggressively during bulk verification, and 429 is explicitly a "slow down" signal with a built-in resume mechanism (Retry-After) that the agent ignored. The registry was cooperating; the agent was not listening.

Edge cases

• Without a Retry-After header, start with a short wait and double it each attempt.
• Cap total retry time so one throttled PR cannot stall the whole verification queue all day.
• If many agents share one egress IP, coordinate their verification schedules or they will throttle each other.

Provenance

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