This is a hypothetical that I'm documenting for investigation. The idea was inspired by suganthi.mani's discovery in SERVER-48518. Unlike SERVER-48518, this out of order timestamp condition is only problematic when WT is running with durable history.

Consider the following sequence where a primary accepts some writes, rolls them back, and then as a secondary replicates writes that use the same key-space.

• As primary
• Insert {_id: 1, doc: "A"} @ TS 20 RecordId(5)
• Delete {_id: 1, doc: "A"} @ TS 30
• Stepdown, perform Rollback via refetch to back to TS 10
• Rolls back delete – refetch {_id: 1} from sync source. The document does not exist – do nothing
• Rolls back insert – the {_id: 1} document doesn't exist in the index – do nothing
• Become secondary
• Replicate Insert {_id: 1, doc: "B"} @ TS 15 RecordId(5) RecordId(6)

In this state, there are two update chains with out of order timestamps:
RecordStore: RecordId(5) V3(15) -> V2(30) -> V1(20) See comments
Index: KeyString(1) V3(15) -> V2(30) -> V1(20)

Note the out of order updates in the RecordStore case are not alleviated by SERVER-48453 as this problem would still exist without lazy-initialization.