Closed hzoo closed 6 years ago
Nice, thanks for taking the time! :yum:
Thanks for the responsiveness! haha
Your features are live now.
Awesome! looks like it works!! https://github.com/babel/babel/issues?q=label%3Aoutdated+is%3Aclosed
Actually @dessant I was wondering if you knew why https://github.com/babel/babel/issues?q=label%3Aoutdated+is%3Aclosed only has 157 outdated labels/locked issues atm? I would of thought it was much faster to apply the lock?
It looks like it's supposed to do 30 issues an hour?
@hzoo This is to prevent triggering abuse mechanisms on GitHub. See https://github.com/dessant/lock-threads#why-are-only-some-issues-and-pull-requests-locked
Strange, because other projects continue to be locked. It may have something to do with the latest closed issues all being locked, and the app requesting only the first 30 from the list.
https://github.com/babel/babel/issues?q=updated%3A%3C2018-02-01+is%3Aclosed+sort%3Aupdated-desc
My guess is that we need to iterate through the results until we collect 30 lockable issues, I think there is no search filter for locked ones. I'll look at the exact api responses tomorrow and sort it out.
Wait, this starts to look like an api regression, check the link in my previous comment, there are pull request threads listed that were updated recently, despite the updated:<2018-02-01
filter.
@Ben3eeE, am I missing something?
@hzoo, it seems the filter interprets pull request updating as code changes, while the UI disagrees what updating a thread means:
Issue update filtering is handled correctly, you could limit the bot to issues only and continue the locking process until this is sorted out.
@Ben3eeE yeah I totally understand that and saw that note but I turned the bot 2 days ago so I would expect a lot more issues to be locked. It more feels like every time I turn on the bot or change a setting it would do the 30 issues instead of per hour. And yeah it only takes the latest instead of the oldest?
@hzoo, sorting by oldest first would mean all the previously locked issues get listed first after the initial issue backlog is processed by the bot. The iteration I suggested above is also not practical, because you end up processing the entire issue list, searching for lockable ones.
The current way seems to be the only practical one until there is a filter for locked issues. Issue labeling could be made mandatory to be used as a filter, but that's undesirable.
Ooh I see, the way I'm using it does add a label though - could we add a feature that uses that as the filter (if you provide the label)?
We could, but that won't be reliable either as a solution for projects in general and could cause this deadlock the same way if say you start setting the label after the first few issues are locked. I'd much rather see the update time filter for pull request threads fixed for the github api. :stuck_out_tongue:
@hzoo Oh I misread your question :blush:
@dessant Yeah the way the updated filter works for pull requests seems odd.
Let's track this at https://github.com/dessant/lock-threads/issues/5.
Made a post about this https://twitter.com/left_pad/status/993492191996674048 since a lot of people were mentioning the issues with old comments on twitter!
@hzoo Oh wow! Thanks for spreading awareness, and for the shout out!
Ok made those changes