In test/format, the oldest and stable timestamps are advanced based on some combination of the return of conn->query_timestamp(...."get=all_durable") and the current timestamp.  This is done with a global "timestamp" lock held.  Meanwhile, each worker thread that commits does the following with the "timestamp" lock held.  It gets/incrs the current timestamp, and does session->timestamp_transaction() with that timestamp.  Before doing the commit, it releases the timestamp lock.  A potential race can occur in that gap - a thread that happens to be descheduled could have a timestamp and then the oldest and/or stable timestamp can overtake it before uses it to commit.

The latest changes to test/format make this less likely, as the oldest and stable timestamps will tend to lag the current, but it remains a theoretical possibility.  When/if it hits, there will be some undefined behavior and may give us some odd failures.