Repository navigation
Handle rate limit #1758
Description
Currently rate limit is not being handled at all. Which causes a build from scratch. It would be worth waiting for XX seconds (let's say below <60s) instead of building from scratch as it would still be faster for mid-size/large codebases.
Run actions/cache@v5
Warning: You've hit a rate limit, your rate limit will reset in 18 seconds
Warning: Failed to restore: Failed to GetCacheEntryDownloadURL: Rate limited: Failed request: (429) Too Many Requests: rate limit exceeded
Cache not found for input keys: goofy-b41b01ad3312fe1358359b7522c43860bfdad754166c7f1d385e51766e57b4c0
Reacted by Mike McCready
Activity
inoway46 commentedon Oct 23, 2026
We’ve seen HTTP 429 errors during cache restoration in Node.js’s Linters workflow, including this run. Losing the lint cache can make it harder to finish within the runner’s time limit.
I understand the decision not to retry automatically. Would you consider exposing rate-limit information as action outputs instead—for example, whether restoration failed with HTTP 429 and the
Retry-Aftervalue when available?This would let workflows choose a bounded retry for rate limiting while proceeding immediately on a normal cache miss, without changing the default behavior. Would this approach be worth considering?