We're checking during rollback_to_stable that we roll back all the most recent changes to a given key. In other words, we don't skip some recent updates, then roll back some older ones.
But in a MongoDB test exercising capped deletes, the assertion is firing in the _id index: we have a key that was inserted with a timestamp then removed without a timestamp. The rollback_to_stable assertion is complaining about rolling back the insertion without rolling back the remove (it's not smart enough to figure out that either way the key disappears from the index).
Make a change so the assertion doesn't fire in this case (i.e., make it less strict unless assert=(commit_timestamp=always|key_consistent) is configured for the table.
- related to
-
WT-4315 In rollback_to_stable, only check timestamp order if enforced
- Closed