Cannot rollback to a suggested edit which was 'improved' by a reviewer

Question

This question of mine has had an edit suggested, which was improved by one of the reviewers. Because of this, both the suggested edit itself (revision 2) and the improved edit (revision 3) are added to the revision history.

I decided I like the suggested edit more than the improved one, so I'd like to rollback to revision 2. I get the familiar popup 'Are you sure you want to rollback', but when I confirm, the page reloads, but there is no rollback. (Normally, you'd see the new revision on top of the list.)

I double-checked with @rene in chat and it's happening for him as well. He mentioned that the suggested edit only added a tag - the rollback mechanism might be checking just the body and title of the question.

It might be that it's not intended at all to rollback to that revision, but then the rollback link should be disabled/hidden.

Based on a SEDE query I found another case where an improved tag-only edit cannot be rolled back to:

• Organizer.displayName is null for some users
• Compare String using tMap
• Rearrangement based on matching text in Excel?

It's not consistent, though, as for some other questions in that query (e.g. this one) the rollback works as intended.

Answer 1

There's a bit of history to this bug. But the problem boils down to one of establishing a consistent chronology when actions can happen concurrently:

• An Improved suggested edit always applies two edits simultaneously: the suggested edit, and the improved version. However, the Improved version must be considered a "later" revision.
• It is possible for two editors to independently submit an edit to the same post simultaneously, or at least close enough to one another that the processing overlaps. Which one should be considered "later" is debatable, but we should try to pick the same one consistently.
• Due to how edits are stored (title, tags and body each a separate row in PostHistory) and the existence of a grace period for edits, it is entirely possible for multiple revisions to share the same timestamp while having interleaved IDs for their component parts.

The canonical solution to this is the method used to generate the revision history (/posts/[id]/revisions):

• Group PostHistory rows by RevisionGUID
• Order them first by the lowest creation date for each group, then by the lowest ID for each group

For your post, that looks something like this. This occasionally produces some very weird results, but in normal situtations it does the right thing and does it consistently.

However, there was a different routine responsible for retrieving a specific revision (for editing or rolling back), and it used a much different approach, relying on the CreationDate of a specific revision's PostHistory entries being greater than all those preceding it and less than all those following. This broke pretty reliably whenever those assumptions didn't hold, which happens consistently when Improve is used.

The fix here involves establishing a consistent chronology using more or less the same approach as the one used to generate the revision history itself, and then relying on that to compose a specific revision. Something like this.