Snapshot isolation cannot be guaranteed for operations that ignore prepare conflicts. This means that two reads of the same record in the same snapshot can return different results. In practice, the assertion added by SERVER-40620 fails if an index points to a non-existent record. This may return false positives if a record is fetched in the collection after a prepared transaction that deletes that record commits.

We cannot enforce the DataCorruptionDetected assertion if we are also ignoring prepare conflicts, or we will continue to get false positives.

Original description:

SERVER-37364 made the transaction coordinator return the decision as soon as the decision is persisted. As a result, the client is no longer guaranteed to see the effects of the transaction immediately after the commitTransaction returns. Based on this evergreen patch, a find command that is run immediately after an update shard key operation (but before the transaction finishes committing in the background) can fail with DataCorruptionDetected error (added in SERVER-40620).