Bors sometimes doesn't see retry messages until a ping

Hi,

On a couple of occasions, I've noticed that bors doesn't respond to bors retry messages and then later a bors ping will cause bors to think the retry requests are for the ping.

It seems like bors sees the messages in the wrong order. In one PR it seems bors saw:

  • bors r+
  • bors retry
  • bors retry
  • bors ping

As:

  • bors r+
  • bors ping
  • bors retry
  • bors retry

Resulting in "pong, pong, pong".

Here's a PR where this happened:
https://github.com/gabi-250/rust/pull/23#issuecomment-458846956

Looks like a bug?

1 Like

Yeah, I think I know what the bug is. It's puzzled me for awhile why retry would fail when you ran it more than once in a row, but now I see it.

When you run bors retry, it looks up in a logging table the most recently-run command for this PR. The first time you ran retry, the most recently run command was r+, so it ran bors r+ and as such tried the build again.

When you ran bors retry the second time, it consulted the logging table for the most recently run command. It got back retry, so it ran bors retry, so it consulted the logging table for the most recent command. It got back retry, so it ran bors retry, so it consulted the logging table for the most recent command, and, as you already noticed, it looped for awhile. Until you eventually ran bors ping, adding a new entry to the log which it instantly picked up (command resolution isn't run in a transaction, so there's no isolation there).

In any case, pull request opened!

https://github.com/bors-ng/bors-ng/pull/588

1 Like