Time sensitive: GitHub Actions Cache rate limits (from GitHub staff)

[Link-]

To preserve the health of our services and reliably serve all GitHub Actions Cache users, the following rate limit will take effect immediately:

200 cache entry uploads per minute per repository.

If you exceed this limit, you will receive a 429 response and an error message indicating that you have exceeded the rate limit.

You should not retry your request until after the time specified in the Retry-After header has passed. If your request continues to fail due to this rate limit, implement exponential backoff between retries, and throw an error after a specific number of retries.

This limit helps prevent abuse and denial-of-service attacks and ensures that the service remains available for all users.

Important

Introduce the needed changes to your library so that the rate limit errors are retried as per the recommended schedule.

Update your actions and libs

If you are using any of the following actions or depend on any of these libraries:

• https://github.com/mozilla-actions/sccache-action
• https://github.com/mozilla/sccache
• https://github.com/apache/opendal
• https://github.com/DeterminateSystems/magic-nix-cache

Introduce the needed changes to maintain a high cache hit/miss ratio, or follow-up with the authors of those libraries on the progress of these changes.

Thrashing

It has also come to our attention that a substantial number of repositories adopting this library (or action) are exhibiting consistent cache thrashing behavior.

Cache thrashing occurs when cache entries are frequently evicted and re-created in a continuous cycle, preventing effective cache utilization. This happens when your workflow generates more cache data than can be stored within your available cache storage quota.

By default, GitHub Actions provides 10 GB of cache storage per repository. When this limit is reached, GitHub automatically evicts the least recently used cache entries to make room for new ones. If your workflows consistently produce cache data that exceeds this limit, the cache is constantly being written and evicted—resulting in thrashing.

This leads to:

• Wasted compute time spent creating caches that are immediately evicted
• Increased network bandwidth consumption
• Little to no performance benefit from caching

To avoid thrashing, consider increasing your cache storage limit. For more information, see "Usage limits and eviction policy."

[MoLow]

CC @nodejs/build

[Renegade334]

sccache / opendal::services::Ghac should already be honouring rate limiting AFAIA.

As for cache size, the cache eviction time right now is about a day, although I imagine there are circumstances (eg. concurrent builds from multiple different release branches) that might push us close to the limit.

[Link-]

As for cache size, the cache eviction time right now is about a day, although I imagine there are circumstances (eg. concurrent builds from multiple different release branches) that might push us close to the limit.

@Renegade334 - the reason I'm reaching out is because sccache and opendal need to make a few adjustments to fully honour our rate limiting. These rates have been very recently introduced. I've already contacted them to adjust their implementation.

You are flagged in our system as one of the highest repos to exhibit thrashing behaviour. Cache eviction happen near realtime right now, and cache entries are no longer held for 24 hours before eviction as was the case in the legacy service. You're dealing with a re-written service that is much more performant.

I would highly advise you to increase you cache storage limits to > 10GB to reduce your thrashing levels and upgrade your workflows when sccache pushes a new release with the fixes we asked for.