State restoration fails if a repo has many caches

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/stale will fail to restore its state and then will fail to update the state.

Action version:
9.0.0

Platform:

Ubuntu
macOS
Windows

Runner type:

Hosted
Self-hosted

Repro steps:

Create a repo set up with actions/stale with a low operations-per-run and enough issues that a single run cannot process them all.
Have actions/stale run, which should create the "_state" cache entry.
Run other actions to create various other cache entries, until visiting https://api.github.com/repos/{owner}/{repo}/actions/caches no longer includes "_state" as it has been pushed to the second page of results.
Have actions/stale run 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

The saved state was not found, the process starts from the first issue.

Processing begins from the first issue. Then at the end it reports

Failed to save: Unable to reserve cache with key _state, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/master, Key: _state, Version: fa41d75081481069cfb6b92a5f83a94c6e06ef3ab2e6b762649ac5f86f46153f

Analysis:
The checkIfCacheExists function 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

    
           const checkIfCacheExists = async (cacheKey: string): Promise<boolean> => { 
        
             const client = getOctokitClient(); 
        
             try { 
        
               const issueResult = await client.request( 
        
                 `/repos/${context.repo.owner}/${context.repo.repo}/actions/caches` 
        
               ); 
        
               const caches: Array<{key?: string}> = 
        
                 issueResult.data['actions_caches'] || []; 
        
               return Boolean(caches.find(cache => cache['key'] === cacheKey)); 
        
             } catch (error) { 
        
               core.debug(`Error checking if cache exist: ${error.message}`); 
        
             } 
        
             return false; 
        
           };

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 key and ref parameters 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.

@anomiex

Hello @anomiex
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

Fix checking state cache (fix actions#1136), also switch to octokit m…

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@0980a21d84c23bd4d8c62b0958f47f25822286f2

FWIW, 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 exists

I 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.

ci(stale): bump operations-per-run (#4625)

ci(stale): bump operations-per-run (gnolang#4625)

Fix checking state cache (fix actions#1136), also switch to octokit m…

CI: Switch back to actions/stale now that upstream issue is fixed

Navigation Menu

Repository navigation

State restoration fails if a repo has many caches #1136

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	const checkIfCacheExists = async (cacheKey: string): Promise<boolean> => {
	const client = getOctokitClient();
	try {
	const issueResult = await client.request(
	`/repos/${context.repo.owner}/${context.repo.repo}/actions/caches`
	);
	const caches: Array<{key?: string}> =
	issueResult.data['actions_caches'] \|\| [];
	return Boolean(caches.find(cache => cache['key'] === cacheKey));
	} catch (error) {
	core.debug(`Error checking if cache exist: ${error.message}`);
	}
	return false;
	};

State restoration fails if a repo has many caches #1136

Description

Activity

v-HarithaVattikuti commented on Feb 22, 2024

Georgegriff commented on Jun 24, 2024

andig commented on Jun 29, 2024

PlayLikeNeverB4 commented on Nov 1, 2024

thehowl commented on Aug 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions