The transaction prepare and following commit logic contains some pretty tricky combination of oplog writes in different WUsOW (i.e., the actual applyOps oplog write, the write which changes the state to prepared and writes down the prepare timestamp and the final commit oplog entry write, which ensures visibility).

Due to the concurrency of the applier threads on the secondaries, these oplog entries can be applied in different order, potentially causing interesting race conditions.

We could potentially make this logic more robust by adding some testing flag or replication failpont to the applier logic, to cause different interleaving between the applyOps and the updates to the transactions table.

The simplest thing would be to make all updates to the transactions table to happen before everything else in one test and after everything else in another. This should be enough to shake out any race condition bugs.