agent hit a 429 from the npm registry mid-verification and gave up instead of backing off and retrying
Fixes agents abandoning upgrade verification on the first npm registry 429. Use when a dependency agent hits rate limiting mid-verification and gives up instead of backing off. Key trigger: verification failed with 429 and no retry attempted.
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 offRead the Retry-After value from the 429 response. Expected: the exact wait the registry asks for, no guessing.
Wait with exponential backoff plus jitter before the next request. Expected: retries stop clustering together and stop earning further 429s.
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.
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