Repository navigation
State restoration fails if a repo has many caches #1136
Description
Activity
Hello @anomiex
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.- added a commit that references this issue
on Apr 10, 2024 I notice there is a linked pr #1152 is there any possibility this might move forward?
We're seeing this, too. A fix would be highly appreciated. Handler might end up in
Warning: If you think that not enough issues were processed you could try to increase the quantity related to the operations-per-run (https://github.com/actions/stale#operations-per-run)) option which is currently set to 30
otherwise.
As a workaround I'm using the action in the linked PR and it works well.
- uses: itchyny/actions-stale@0980a21d84c23bd4d8c62b0958f47f25822286f2FWIW, this also shows up with the given error:
Failed to CreateCacheEntry: Received non-retryable error: Failed request: (409) Conflict: cache entry with the same key, version, and scope already existsI think it may just be a new error message, updated from the old one.
It would be much appreciated if the maintainers could look at the open PR.
Reacted by Ruth Comer- added a commit that references this issue
on Aug 11, 2025 - added a commit that references this issue
on Aug 26, 2025 - added a commit that references this issue
on Dec 5, 2025 - added a commit that references this issue
on Feb 8, 2026 - added a commit that references this issue
on Feb 8, 2026
Description:
If a repository has many caches being used between runs of
actions/stale, such that the "_state" cache entry is not on the first page of results returned from the list caches API,actions/stalewill fail to restore its state and then will fail to update the state.Action version:
9.0.0
Platform:
Runner type:
Repro steps:
actions/stalewith a lowoperations-per-runand enough issues that a single run cannot process them all.actions/stalerun, which should create the "_state" cache entry.https://api.github.com/repos/{owner}/{repo}/actions/cachesno longer includes "_state" as it has been pushed to the second page of results.actions/stalerun again.My test repo for this issue is at https://github.com/anomiex/test-stale.
Expected behavior:
For step 4, the state is restored correctly and processing continues from where the previous run left off.
Actual behavior:
In step 4, near the start, it reports
Processing begins from the first issue. Then at the end it reports
Analysis:
The
checkIfCacheExistsfunction only checks the first page of results, using the default value of 30 entries per page.stale/src/classes/state/state-cache-storage.ts
Lines 33 to 46 in 3f3b017
While you could fix the bug by adding pagination so the relevant cache entry is found even if it's not on the first page, a more performant fix would be to make use of the
keyandrefparameters to the list caches API to specify the branch and key that we actually care about.I suppose doing both would be an even better idea, just in case some repo is creating a lot of other cache entries with the "_state" prefix.