When the PullRequestBot schedules CheckWorkItem, the state of the PR it evaluates is a stale instance from when the CheckWorkItem was submitted. This means that when the WorkItem runs, it may see the WorkItem as open when it is in fact integrated already, which can lead to inconsistent states.

Yesterday we observed that happening (in an internal Gitlab instance so can't link) which resulted in the following confusing error being posted in the PR post integration:

"This PR only contains changes already present in the target"

I'm not sure exactly how this should be solved yet. It will require some careful consideration. The obvious fix is to always refetch the PR at the start of WorkItem::run, but we need to consider if there are any unwanted consequences to doing that.

My assumption now is that the offending CheckWorkItem was submitted from PullRequestBot::getPeriodicItems, which had read the PR as open. It will only submit CheckWorkItems for open PRs. The CommitCommandWorkItem that performed the integration was executing at the same time, finished, and scheduled a CheckWorkItem afterwards. This CheckWorkItem started running before getPeriodicItems returned, otherwise the new CheckWorkItem from getPeriodicItems would have been discarded as a duplicate in the run queue.