Repeatedly running integrity checks can repeatedly decline pull requests that are in an inconsistent state

Issue Summary

When integrity checks run, they loop over each pull request in each repository and, if the pull request has a merge activity, the checks verify that the merge commit still exists. If it doesn't, an attempt is made to reopen the pull request.

Depending on the repository's state on disk, however, it may not be possible to reopen the pull request. Some examples of why a pull request might fail to reopen include:

• Another pull request is already open between the same two branches
• The source and/or target branch for the pull request do not exist
• The source branch exists, but does not reference any commits that are not already referenced by the target branch (nothing new to merge)

If the source branch does not exist in the repository, the pull request is updated to mark it as declined instead of merged to allow re-pushing the source branch and reopening the pull request later. However, when declining, the system doesn't first check to verify that it hasn't already declined the pull request previously. This can result in multiple "Integrity checker DECLINED the pull request" activities, one for each time integrity checks are run.

Steps to Reproduce

• Restore a partial backup, or a backup that was taken without locking both the filesystem and database, such that the database includes pull requests which are marked as merged but for which the repository no longer includes the merge commit or the source branch
• Trigger integrity checks (Data Center license only)
• Trigger integrity checks again

Expected Results

Pull requests are transitioned from "Merged" to "Declined" the first time integrity checks are run, but are not re-declined the second time when they still can't be reopened.

Actual Results

Each run of the integrity checks adds a new decline activity to the pull requests.

Some related logging:

2019-03-15 03:47:35,811 WARN  [Caesium-1-2]  c.a.s.i.i.DefaultIntegrityCheckReporter PROJ/repo[1]: Pull request #1 is marked merged but the merge commit could not be found on the target ref. Trying to restore integrity by reopening
2019-03-15 03:47:35,848 WARN  [Caesium-1-2]  c.a.s.i.i.DefaultIntegrityCheckReporter PROJ/repo[1]: Pull request #1 could not be reopened, declining instead. (Reason: fromRef could not be resolved)
2019-03-15 03:47:35,863 INFO  [Caesium-1-2]  c.a.s.i.i.DefaultIntegrityCheckReporter PROJ/repo[1]: Pull request #1 declined successfully

Workaround

There are no workarounds. This is purely a cosmetic issue, and doesn't impact any functionality either while integrity checks are running or after they've completed. Aside from having multiple declined activities in their overview, such pull requests can still be viewed, and can still be reopened later (assuming their source branch is re-pushed with new commits that are not already on the target branch).