GitHub Actions not removing Stale label

[Marterich]

As seen in #2087 the Stale label doesn't seem to be automatically removed by the GH action even though there is activity.

@og-mrk maybe revisit the action
I would do it myself but I have a hard time finding the time at the moment

[og-mrk]

Hello @Marterich
This issue is made possible in the first place because the actions/stale GitHub Action has an optimization that allows it to cache the result of the previous run into a .tar compressed archive.. for whatever reason, the action has by default the permission to Create the .tar archive.. but doesn't have the permission to delete it..

so it resulted in a lot of issues being skipped when found because the action logic sees the cache and finds these issues have been check before.. so it just skips them (look into this line for the issue you've highlighted & this line for the warning about not having right permission to delete the cache, showing Error delete _state: [403] Resource not accessible by integration).

All of this started when I've fixed this workflow by doing a Stale & Close process in PR #2139.. but at the time, I didn't realize this action has a limit for processing items (PRs & Issues) set to 30 items per run by default.. because it couldn't process all the opened PRs & Issues, it has created the cache.

So the answer should be simple, just give the action the correct permissions to delete the cache file.. right?

Well.. after some searching online ( I did notice this caching issue before.. but didn't like the possible solution, so I left it as is ).. I found the only solution on the Action's GitHub Repo.. which's giving actions: write permission, which's waaayy too permissive for this quite simple workflow, opening to a whole field of possible security risks..

which I didn't want to simply open a PR, and say "Hay, even though this fixes this issue, it also opens a lot of potential security-related problems." yahh, this would open a lot of questions, especially because I've pretty much been the only one maintaining this workflow for some time.. which will, understandably, make other contributors and Chris himself have some questions for me to answer.. Also, before switching to actions/stale, there was some Javascript code which I also maintained.. I think you can see why I avoided all of this 😅

My bad for the long response, but the TL;DR of it is:
I don't know if we should roll back to the old code for Workflow.. or try to see if actions: write permission isn't as dangerous as some people portrait it to be (the argument is, if you keep your GitHub account or Organization safe, and have 2FA enabled.. then there shouldn't be any problems with it + don't merge workflow changes without reviewing it, of course 😅).

[og-mrk]

Update on this issue

Found out that on this PR made in apache/eventmesh repo, they've solved this issue by simply reverting back to older version (specifically v8) of the actions/stale GitHub Action!

Will make a PR that does the same as the one linked above 👍