Rollback to stable missed to remove the historical versions that are written as part of the checkpoint reconciliation for the newly inserted keys when the rollback removes these keys to stable operation because of unstable updates.
Not removing the unstable entries from the history store can lead to an WiredTiger assertion failure when these updates are reinserted as part of the oplog replay and moved to the history store again.
Currently, as part of
WT-9846 solution, we are fixing this issue to rely on the updates present in the update chain to remove the history store versions when none of them are found stable as part of the rollback to stable operation.
The above-proposed solution is simple and has very minimal impact, but relying upon the update chain to decide whether to remove the history store versions doesn't sound good as in future we are going to aggressively remove the written updates that are written to the disk from the update chain, so instead of that solution, we want to go with the approach of scanning the history store table at the end of the rollback to stable operation to remove any unstable updates.
Allowing rollback to stable to scan at the end in all the scenarios can uncover the scenarios that are not yet handled. As part of this ticket fix all those missing scenarios and remove the simple solution that is implemented as part of the