In some scenarios when the history store key is written in two pages, it can lead to a scenario where the latest history store update can be behind the old history store update due to the global visibility.

1. Key 1 -> has two updates with timestamps 10, 20. After reconciliation, the 20 timestamp update is written to the data store and (10-20) as the history store. The history store page is also reconciled.
2. A new insert happened on that key with the timestamp 30.
3. The oldest timestamp is set to 40. During reconciliation, the update with timestamp 30 is written to the data store as 0.
4. A new insert happened with timestamp 60 and it is reconciled to the data store and the old version with timestamp 0 is moved into the history store, but this version inserted in a new page compared to the history store version (10-20).
5. Checkpoint occurred with the above data files.
6. RTS happening on the key leads removal of the key due to the restoring of (10-20) history store into the data store.

The solution to the above problem is to let the Rollback to stable verify the stop timestamp of the history store record is less than the stable timestamp and its stop transaction is visible to the checkpoint snapshot.