Several times now, we've had a situation where audits are re-sent due to a rebase. Basically, what seems to happen is that someone rebases on top of an old commit -- by mistake -- and when they push, any audits that were rebased get re-opened, since the sha now differs.
Here's a report how one user got into this state. I'm not sure I totally understand it, but hopefully you guys will. :-)
> I have a feature branch (local+remote) that I'm creating diffs from. I went to land one and got "Usage Exception: There are multiple revisions on feature branch 'myfeaturebranch' which are not present in 'parentbranch'" with a list of all of the diffs I had done off of parentbranch. My guess is that happened because at one point I renamed parentbranch from its original name. I then switched to parentbranch and did "git pull featurebranch." Then I did "git push origin parentbranch" but for some reason it said I was behind and needed to pull. I did "git pull origin parentbranch" and it pulled in every commit that I authored in parentbranch or had been rebased into parentbranch. I'm pretty sure that what happened was that it made new commits with me as the committer even for things that I didn't author. I should have stopped there but I did "git push origin featurebranch" which kicked off new duplicate audits. It also caused me to close someone elss's open revisions.
The ideal solution would be to not create the duplicate audits in this scenario, but that may be difficult. A 90% solution would be to maybe make it easy to identify audits where the author and committer differ, and automatically close them all? Something that was like "Find all audits where the author and committer differ and were created less than X minutes ago." would be a useful search, especially if combined with an 'accept all' button or some such. Then we'd just point people to that whenever we notice a mistaken rebase+push like this.