RecordIds by MDB are generated with an auto-incrementing integer. Initialization on a restart, or after rollback opens a cursor (with data at the stable timestamp) and does one reverse step to get the largest id in use for a document.

Now consider the following sequence with durable history:

• Set OldestTimestamp 1
• Insert RecordId(1) -> A at TimeStamp(10)
• Insert RID(2) -> B at TS(20)
• Delete RID(2) (B) at TS(30)

If we were to restart and initialize the next record id, we'd start issuing new documents RID(2). Normally this is fine. Any new replicated user writes must be generated with a timestamp larger than 30, so the update chain for RID(2) will remain valid.

However, when reconstructing prepared transactions, the prepare timestamp (and thus any following commit timestamp, but not the durable timestamp) may be arbitrarily old.

In this example, after initializing the next RID to 2, if we were to reconstruct a prepared transaction from TS(10) that performs an insert on this collection, we'd get the following update chain (from oldest to newest):

RID(2) => B @ TS(20) -> <tombstone> @ TS(30) -> PreparedInsert @ TS(10)

Committing the prepared insert at a value between 10 and 30 results in wrong results/inconsistent data when reading at those timestamps.