Stale workflow fails to override cache.

[mshima]

Description:
We have a stale workflow: https://github.com/jhipster/generator-jhipster/blob/main/.github/workflows/stale.yml

At first run it successfully generates a cache entry.

After that, the cache is never updated and is reused, so cached entries are never analyzed again.
See builds 599-605 at https://github.com/jhipster/generator-jhipster/actions/workflows/stale.yml

See 2 consecutive days have same cached issue numbers:
https://github.com/jhipster/generator-jhipster/actions/runs/7689412024/job/20951825772
https://github.com/jhipster/generator-jhipster/actions/runs/7682085625/job/20936000418

The error reported is:
Warning: Error delete _state: [403] Resource not accessible by integration

Are we missing a configuration? A permission maybe? There is no info in the docs.

Action version:
v9

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
Links above.

Expected behavior:
A new cache should be written at every run.

Actual behavior:
New cache are not been overridden

[HarithaVattikuti]

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

[csuermann]

Looks like issues already processed in previous runs never get closed due to the cache.

.github/workflows/stale.yaml:

name: 'Close stale issues'
on:
  workflow_dispatch:
  schedule:
    - cron: '30 1 * * *'
permissions:
  issues: write

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v9
        with:
          stale-issue-message: 'This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.'
          days-before-stale: 30
          days-before-close: 5

Run actions/stale@v9
Cache Size: ~0 MB (307 B)
/usr/bin/tar -xf /home/runner/work/_temp/f4844f75-67b0-4546-8244-42b90d2f9d54/cache.tzst -P -C /home/runner/work/xxx --use-compress-program unzstd
Cache restored successfully
state: restored with info about 12 issue(s)
Starting the stale action process...
Processing the batch of issues  #1  containing  11  issues...
[#239] Issue #239
[#238] Issue #238
[#237] Issue #237
[#235] Issue #235
[#234] Issue #234
[#231]            issue skipped due being processed during the previous run
[#229]            issue skipped due being processed during the previous run
[#227]            issue skipped due being processed during the previous run
[#222]            issue skipped due being processed during the previous run
[#221]            issue skipped due being processed during the previous run
[#219]            issue skipped due being processed during the previous run
Batch  #1  processed.
No more issues found to process. Exiting...
Statistics:
Processed issues: 5
Fetched items: 11
Operations performed: 2
Github API rate used: 2
Github API rate remaining: 997; reset at: Wed Feb 07 2024 02:59:48 GMT+0000 (Coordinated Universal Time)
state: persisting info about 0 issue(s)
Warning: Error delete _state: [403] Resource not accessible by integration
the state will be removed
Received 307 of 307 (100.0%), 0.0 MBs/sec

[mshima]

As workaround:

• manually delete the cache.
• make sure every run processes every issue so cache is not created.

[anomiex]

I think the docs are missing that the actions: write permission is needed.

I saw the "Error delete _state: [403] Resource not accessible by integration" error here in a test repo while trying to reproduce a different issue, and based on the docs for the API used I added that permission and the error went away.

[suyashgaonkar]

Hi @mshima , we did investigation with provided information for the issue. Tried to reproduce the issue with actions/stale v8 and v9 both, and everything seems to be working fine on our end. We did not get the mentioned error Warning: Error delete _state: [403] Resource not accessible by integration.
For cache to get generated and getting restored the number of operations happening with Github API should exceed the value set in the operations-per-run (deault:30). If not so then we get "The saved state was not found, the process starts from the first issue." in the logs.
you can refer the following links :
https://github.com/actions/stale?tab=readme-ov-file
https://github.com/actions/stale?tab=readme-ov-file#operations-per-run
Please let us know if you still need any assistance on this as we see recent runs for the mentioned workflow has no issues in the provided repo too. You can check attached the screenshots for more details.

[suyashgaonkar]

Hi @mshima , We are awaiting for your response on the issue. Please let us know if we can close this issue if there are no further queries.

[mshima]

@suyashgaonkar thanks for the response.
Screenshots from #1131 does not demonstrates the issue since it do not show that the cache is correctly overridden in second run.

We've not had more problems since stale only processes at most 1-2 issues per day in our use case. At adoption we had more than 100 stale issues pending.

[ericLemanissier]

@mshima you probably want to try my proposition from #1183.
For this, you can replace uses: actions/stale@...with uses: actions/stale@ericLemanissier/patch-2 and remove actions: write from https://github.com/jhipster/generator-jhipster/blob/main/.github/workflows/stale.yml