The action gets stuck checking existing stale PRs without getting to new ones

[mezz]

Describe your issue

I have a long "stale" time of 90 days, and then 30 days to close.
The stale bot uses up all my API actions on iterating over existing stale commits and checking them for comments, and it never gets to apply the stale label to everything that needs it.
I am left with a handful of issues marked stale, but many more need the label.

Your stale action configuration

https://github.com/mezz/JustEnoughItems/blob/def1bfdcba3af124de6fe78fd23ed39c7f1d41a6/.github/workflows/stale.yml#L14-L28

Further context

I think the bot needs a strategy that lets it apply stale labels first, and then check random stale commits for their comments. If the action can persist some data between runs, it would be nice for it to track which issue it left off on so that it can start from there on the next run.

[steveluscher]

Oh no. And that's with only ~200 issues and ~20 pull requests? I'm definitely going to run into this problem then, having ~1000 issues and ~300 pull requests.

[dsame]

Hello @mezz , i thought about different strategies and none of them seems perfect to me. But what do you think about just descending sorting the issues by updated_at every time? This way the issues that were not be labeled go first and are updated to be checked next time last. Do you see any disadvantages of this approaches?

[mezz]

Hello @dsame ,
It is a bit difficult to predict but I think that may at least get things labeled.
I can imagine that the oldest stale issues will not get closed with this strategy.
If you can create a sorting option, I am happy to try it out and let you know if things improve though.

Are you able to store any state between runs, so that it can "resume" when it runs out of actions?

[jklymak]

We are discussing trying this in Matplotlib (>1600 open issues and > 300 open PRs). It's a little unclear what "operations-per-run" refers to - will we be making >1900 operations just to get the state of each Issue/PR? Or is it 20 operations in batches of 100? After that, is each label/close an operation? Sorry if this should be clear - not super experienced with what GH Actions consider a call or not.... Note that https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limits-for-requests-from-github-actions claims Actions get 1000/h, so maybe we don't need to limit to anything as low as 30... Thanks for any help; hopefully these clarifications are not hijacking this issue.

[dsame]

@mezz in theory it is possible to use the same storage that is used for caches to store the state but it will require extra API calls just to "get into the previous state" - that i want to avoid.

[mezz]

I believe the first priority for the system design should be correctness, and from there we can optimize if we can.
Unless there is a better solution that comes to mind, I am not sure how else this bot can work correctly.
My stale bot has maxed out its API calls for months, unfortunately wasting them without making much progress, so requiring extra API calls seems like a low price.