Handle pull_request_review events with 'action': 'edited'

[danuker]

There was an erroneous GitHub event for a newly-created pull_request_review with the action being edited.

Think of how to handle these events, as they need to be acted on (but only if really freshly created), and an 'action': 'submitted' event might not be created for them.

Example: This PR review coupled with this processing log

In case the MS link expires, here is the query:

traces
| order by timestamp
| where timestamp > todatetime('2022-03-08T17:36:36.38Z')
| where timestamp < todatetime('2022-03-08T17:36:36.42Z')
| project timestamp, message, severityLevel

[adiroiban]

I don't understand the issue.

The idea, is that "an action" should only be triggered by the initial comment.
Further edits should be ignored.

If you enter a typo and then want to trigger it again, you need to leave a new comment

[danuker]

If you look at the log of the request received from GH, the action is edited in spite of the fact that I did not edit anything at 17:36Z. You can widen the timestamp endpoints in the log query to see some more log lines, but only one other comment appears, even if I had two comments.

You can use Python pprint format the logs starting with {'action': 'edited', 'review':[...] into a dictionary, to see what is sent by GitHub.

Unrelated bug: One of the comments might be missing because either GitHub or Azure fails to process such quick bursts of requests.

The "edited" action is plainly wrong, and comes from GitHub. I have no explanation for it other than a GitHub bug; it should be 'action': 'submitted', because I have never edited the PR review.

---

I was thinking triggering the hook again on edits would be a no-op, because the same ticket state would be desired, if the hook command did not change.
But there are some cases it is not a no-op (like when you edit an older comment, after some of the reviewers offered feedback, you don't want to ask them again to review). So the solution I proposed in the ticket is not a good one.

Now, I see two options:

• Hope GitHub does not make more glitches like this, and ignore this bug
• Try to guess which "edited" actions are actually creation ones, by seeing if the changes field is empty, or if data['review']['submitted_at'] exists but data['review']['updated_at'] does not.

What do you think we should do?