Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/build/cmd/gopherbot: don't fight humans #21312
In #21280 it tagged the issue as
This also happened in #22302:
When I removed it once more about 45 minutes later, the issue didn't happen again:
That's right. I've checked the code, and it certainly has the code to not fight with humans. For example, for the
It does work the second time; the bot seems to fight at most once per issue/task.
It feels like a timing/race condition bug (not a Go race condition, but a general one). It might happen that the
I'm not completely sure how it's possible that the documentation label is removed yet
Perhaps it's worth looking more into that direction; I just wanted to share what I know so far.
Yet another thing I noticed recently that I suspect is related.
In issue #24850, if you look at the issue events API, you can see gopherbot actually applied the "Proposal" and "Documentation" labels three times each. It wasn't fighting humans, but I suspect the underlying reason is similar: it might not receive the "label has already been applied" information quickly enough and ends up iterating over "this label should be applied on this issue because it's not there yet" code 3 times before finally seeing that the label has been applied.
It's not visible in GitHub's UI because it collapses nearby "apply label" events into one, but effectively what happened was this (in the span of 2 seconds):
I reported this to GitHub separately (i.e., it should probably be disallowed at API level to apply the same label more than once in a row). But gopherbot shouldn't be trying to do that either.
(One hacky idea for a fix is to add some delays between gopherbot taking actions, so it's slower (like a human) and has less chances of making repeat actions it shouldn't. But of course that's not as nice as a more proper that doesn't doesn't depend on timing.)
I filed #27058 but I'm closing it as a dupe of this. In the issue referenced there, I did a "gopherbot please remove label documentation" and then saw
(indicating that the label was removed and then immediately re-added) presumably because the issue title contained the word "documentation" at that time.
Another: #28103. I was expecting it to happen, so I fired up a local copy of
I have a good grasp of the underlying cause now. The problem is that
It's as I guessed in #21312 (comment), except now I have data to back up that hypothesis.
Here's a log of
What happens is the mutation for "this issue no longer has a label [that it should have according to the rules]" comes in a few seconds before the "there was an unlabel event for this issue [because a human has unlabeled it]" mutation.
I'm going to file a
I'm going to test this approach and confirm it works as expected.
Starting to have second thoughts about the proposed workaround. In the CL 142362 commit message, I wrote:
It's true that a slower reaction time for gardening new issues is unlikely to be problematic. However, I've realized
For example, I notice people sometimes apply the
If gopherbot ends up taking 15-30 seconds to respond (conceivable if there's a lot of continuous corpus activity), it may seem that it's broken or lagging, and as a result quite detrimental to the user experience and the ability to rely on it.