In txn_timestamp.c, __wt_txn_global_set_timestamp validates and sets user-provided global timestamps. The validations try to ensure that the oldest and the stable timestamps are only set to move forward. There is an inconsistency in the validation. Imagine a case where global oldest_timestamp and stable_timestamp are set to 10:

• If the user calls to set the oldest_timestamp=8,stable_timestamp=8. We validate that the new oldest being set is not newer than the new stable, otherwise, we would generate an error. Later when we realize that the timestamps being set are moving backwards we make the operation a no-op but return a success.
• If the user makes two separate calls, one to set the oldest_timestamp=8, another to set stable_timestamp=8. We compare these values to the existing global values, and error out instead of doing a no-op and silent success.

We should aim to get our API consistent in this behaviour.

This difference in behaviour triggered a bug, being tracked by WT-7968. For a yet undiagnosed reason, test_timestamp_abort is intermittently returning a backwards moving all_durable. The returned value is being set as the oldest and stable timestamp. Since WT-7968 is a CI blocker we fixed it by setting global timestamps differently. - It might also be worthwhile investigating why all_durable timestamp is moving backwards - and then take a call if we want to revert WT-7968 once API has been fixed as part of this ticket.