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.

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.