-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stale issues are not getting closed #1135
Comments
Hello @ForNeVeR |
I don’t know about the log messages but I think when you (un)assign someone that counts as an update. |
This behavior would be absolutely ok for me. However, I changed the assignee list last time at 19th of Dec, and the issue is still not closed, despite the bot being configured to close the issue in 14 days after the last update. |
I have figured it out, though I don't know what to do with that knowledge now. So, the reason is that the bot won't close an issue if there were any comments after the issue was marked as "stale". In my case, the actual use case goes like that:
I no longer believe this is a bug, but I'd like to leave this as a feature request: I want an option to not consider such comments as preventing the issue from being closed. I'd like the bot to treat them just as normal updates: delaying the close, but not totally preventing it. |
(Notably, in this case there are really no comments, but I've changed the issue assignee, and that seems to be considered as a comment as well.) |
That's not the reason for everyone. I saw even no comments after bot marked as stale and still inactivity time passed and stale action not closed issues, but interesting is that all not closed are from February, but bot closes issues from other months (start-date isn't configured, so it's not that) 😄. |
Hello @ForNeVeR , We tried the provided workflow and investigated the issue, we are not seeing issues as it is able to put lables to issues and close them too. One thing we could recommend is not set a negative number like -1 for days-before-stale parameter, as a result no issues or pull requests will be marked as stale automatically. |
Hi @ForNeVeR , We are awaiting for your response, you can let us know if you have any queriers or the issue still exists. |
Ugh, I'm sorry, I am not sure it's easy to check if it works correctly :( I have applied a patch to my fork and my workflow seems to work with this patch, but obviously this solution is far from perfect. |
Hi @ForNeVeR , we see that the issue is not reproducible on our end and the mentioned patch has fixed the issue for you, Do you still need any assistance on this or can we close the ticket ? |
Alright, let's close. |
Description:
Bot is unable to close several issues that, I believe, it should actually close. This may be a problem similar to #1007, though that one is closed as not reproducing in v8, and I am on v9 already and it still happens.
Action version:
I use
stale@v9
.Platform:
Runner type:
Repro steps:
In my repository, I use the stale bot with the following configuration:
So, I want it to take the issues with a manually-assigned label
status:waiting-for-info
, and close them if there were no updates in 14 days.It was working well for some of the issues, but I now see several issues it is unable to close.
Let's consider this particular issue: ForNeVeR/AvaloniaRider#303
Expected behavior:
It has been last changed at 2023-12-19, and today's 2024-02-10, more than 14 days have definitely passed. So I expect the bot to close the issue.
Actual behavior:
Actually, bot refuses to do anything about this issue. Here's a relevant log from the last execution, happened today:
From the message
Stale issue is not old enough to close yet (hasComments? true, hasUpdate? false)
, I conclude it doesn't like something that's been happening in the issue comments. But there weren't any new comments after the issue has been marked as stale for the last time. It has been marked as stale and not stale several times during its lifetime, though, so perhaps something about that messes up the bot logic?The text was updated successfully, but these errors were encountered: