I had a chat with haribabu.kommi and we believe there might be an edge case with aborting prepared updates.

When aborting a prepared on-disk value, we "fix-up" the on-disk value by appending the latest history store update into the list so that it can get picked up by reconciliation and written back onto the page displacing the prepared update that was previously there.

In the case where we have an on-disk value, add a prepared tombstone, and then reconcile, we get an on-disk value with the stop pair set and the prepare flag set. If we abort that tombstone, we'll end up doing the same "fix-up" and replace the on-disk value with the history store value. In this case, we'll actually lose the on-disk value which is wrong because we aborted the tombstone in front of the update, not the update itself. In this case, we need to do something similar to "fix-up prepare", except we need to append the on-disk value into the update chain.

This was something we thought of while chatting. So the first step for this ticket is to figure out whether this can actually happen or whether we have some mitigation to prevent this.