We recently fixed an issue in 4.2 where the "all durable" timestamp can go backwards. However 4.2 maintains two variables (1 and 2) that each independently prevent their readers from seeing a value going backwards.

These variables do not communicate with each other and are not synchronized in any way. Thus a read from a method that looks up against one value can see an "all durable" TS. Following that with a read on a different method can see a different "all durable" smaller than the previously observed TS (due to ghost timestamp writes [1]).

A decreasing all_durable can be observed when a startTransaction request has an afterClusterTime and level: "snapshot".

The afterClusterTime first waits for all earlier writes to complete. This logic compares against "variable 1".

Then we open a WT snapshot using the "all durable" read source. This code path compares against "variable 2", breaking the guarantee necessary to read at or after the afterClusterTime.

[1] WT's all_durable only goes backwards on the primary due to "ghost timestamp" writes. On 4.2, this is primarily from a multikey write inside of a multi-statement transaction.