rate limiting Shipped
What this lens looks for
Respect server rate limits and handle 429 Too Many Requests gracefully rather than hammering the server. On a 429, honor the Retry-After header — parse it as either delay-seconds or an HTTP-date and wait accordingly before retrying; when no Retry-After is present, fall back to exponential backoff rather than retrying immediately or on a fixed interval. Track RateLimit-Remaining response headers proactively and slow the request rate down before hitting the limit, instead of waiting to be rejected. Queue and batch outbound requests so they go out at the allowed rate, rather than firing them all at once and retrying on rejection (no fire-and-retry / retry storms).
What its verifier checks
429 responses are handled by waiting and retrying, never by an immediate or tight-loop retry; the Retry-After header is read and honored, parsed for both the delay-seconds and HTTP-date forms; when Retry-After is absent, retries use exponential backoff; RateLimit-Remaining headers are tracked and used to proactively throttle before a 429 occurs; requests are queued/batched at the allowed rate rather than fired-and-retried, so no retry storm can result from rate limiting.