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:

1. 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.
2. Have actions/stale run, which should create the "_state" cache entry.
3. 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.
4. 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.

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.