Grow and jitter consecutive throttle waits in the retrier

[amankrx]

What and why

A throttled response (RetryResult::RetryAfter) inside the throttle budget sleeps exactly what the store asked, with no growth and no jitter. Azure sends no Retry-After on an egress throttle, so every process behind one account sleeps the floor and retries in lockstep until the budget is gone. Retrier::with_throttle_max_wait makes the n-th consecutive throttle wait the ask times 2^(n-1), capped, jittered with the store's retry.jitter, never below the ask, and a plain retry ends the streak. The Azure store passes throttle_retry_max_delay_s as the cap. Other stores are unchanged.

How was this verified?

Four new tests in retry_test.rs with a recording sleep: waits double up to the cap (2, 4, 8, 16, 30, 30). Existing throttle tests pass unchanged, so the default path did not move. Not yet run against a throttling account.

Risk

Low. Only a retrier with a cap set changes, and only the Azure store sets one. The first wait is as before; later waits are longer, bounded by the existing cap. No config or wire change.

AI assistance

An agent drafted the change and I reviewed every line.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
nativelink	Ready	Preview	Oct 16, 2026 2:22pm UTC
nativelink-aidm	Ready	Preview	Oct 16, 2026 2:22pm UTC

[corcillo]

@amankrx im not sure if per-request throttling is the right approach here, we should probably figure out some high level account wide backoff?

[amankrx]

@amankrx im not sure if per-request throttling is the right approach here, we should probably figure out some high level account wide backoff?

We can add that separately. This should be helpful.