If you commit a series of values to the same key where the durable timestamp of each is after the commit timestamp, and the commit timestamp of the next comes before the durable timestamp of the previous, this is not trapped up front (even with write_timestamp_usage=ordered) and then reconciliation produces a page with an invalid time window that will fail verify. In a diagnostic build it will assert verifying the new page; in a non-diagnostic build things presumably get more exciting.

I expect that if MongoDB did this we'd know about it, so it is probably not a major problem, but it seems like it should be caught earlier. Probably it should be checked by write_timestamp_usage=ordered. Asserting in rec_visibility might be a good second check.

(Not sure whether this pattern counts as out of order or not. My inclination is to think of it as in-order but pipelined. Doesn't matter though.)