Bound object store reads with an adaptive permit pool, Azure first

[amankrx]

What and why

Nothing bounds the reads one process keeps in flight against an object store. A cold worker opens 64 downloads per directory level per action, and an account over its limit answers 503 to most of them, each a wasted transaction and a retry in lockstep. This adds AdaptivePermits, a pool sized the way TCP sizes its window: halve on a throttle, not below a floor, grow by one after sixteen successes. CommonObjectSpec gains max_concurrent_reads (0, unbounded, the default), adaptive_read_concurrency and min_concurrent_reads. The Azure store takes a permit for GET and HEAD, held through the body, and reports what came back. Metrics store.object.read_limit and store.object.read_waits. S3 and GCS follow once this is proven.

How was this verified?

Eight pool tests: halving to the floor, one cut per window, growth to the ceiling, the streak reset, a cut with permits out settled on release, growth cancelling owed permits, a fixed pool, a waiting acquire. Two Azure tests with the mock transport: two 503s then a 200 take the limit from 16 to 4 and fifteen more answered reads raise it to 5; a fixed limit does not move. Not yet run against a throttling account.

Risk

Low by default: with max_concurrent_reads unset no pool exists. Set, reads queue in the process; the floor defaults to 4.

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 4:26pm UTC
nativelink-aidm	Ready	Preview	Oct 16, 2026 4:26pm UTC