Bug: Strange behaviours of Giteabot when request a review of user

[lunny]

ref go-gitea/gitea#26729

[yardenshoham]

I don't see an issue, if @KN4CK3R is requested to review then we ignore his blocking review. Otherwise, his review is relevant and blocks the PR. This matches the icons in GitHub's widget.

What behavior did you expect?

• Related Support PR re-request / self-request review #74
• CC @silverwind

[KN4CK3R]

I think lunny talks about the added lgtm/done label in the last line. The review request should not have changed that because I still blocked the PR at that time. You can't merge the PR if there are still blocking reviews.

[yardenshoham]

The feature request lists the opposite

[KN4CK3R]

But I did not approve the changes previously, I requested changes. Therefore the status should always be blocked.

[silverwind]

I did notice the bot sometimes adding wrong lgtm/done while commenting on code too, so there is definitely some bug there. If the checkmark count is correct, I suspect it's a bug on GitHub's side because they should not have set the checkmark.

[yardenshoham]

Please decide what the desired behavior should be, and I will implement it.

[silverwind]

I see no issue with current implementation. Yellow dot is a requested but not required review. A negative review will block, but if someone re-requests a previously negative review, that will clear the block, which is imho expected.

That said, there is another bug somewhere, if I reproduce it again, I will open a separate issue.

[KN4CK3R]

But the re-request of a negative review does not clear the merge block on Github.

[silverwind]

But the re-request of a negative review does not clear the merge block on Github.

It changes your icon from red to yellow, doesn't it? How is the merge block indicated when not by this icon? Is this merge block state available on GitHub API?

[KN4CK3R]

See this PR go-gitea/gitea#25396
I blocked it and requested changes. My re-review is requested and the icon is yellow. Still the bottom shows that I block that PR at the moment:

[silverwind]

Thanks. We should check whether GitHub API exposes this "changes requested" list and set the block status when user count > 0, irregardless of the review statuses.

[yardenshoham]

• How about Don't ignore change requests when the blocking user is requested to review #105 then?