SERVER-48002 Do not enforce DataCorruptionDetected assertion when ignoring prepare conflicts

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, this can lead
to false positive DataCorrutionDetected assertions.

1 files changed, 6 insertions, 1 deletions

diff --git a/src/mongo/db/exec/working_set_common.cpp b/src/mongo/db/exec/working_set_common.cpp
index c6083642478..33a9f6074e7 100644
--- a/src/mongo/db/exec/working_set_common.cpp
+++ b/src/mongo/db/exec/working_set_common.cpp
@@ -82,9 +82,14 @@ bool WorkingSetCommon::fetch(OperationContext* opCtx,
         // The record referenced by this index entry is gone. If the query yielded some time after
         // we first examined the index entry, then it's likely that the record was deleted while we
         // were yielding. However, if the snapshot id hasn't changed since the index lookup, then
-        // there could not have been a yield, and the only explanation is corruption.
+        // there could not have been a yield, meaning the document we are searching for has been
+        // deleted.
+        // One possibility is that the record was deleted by a prepared transaction, but if we are
+        // not ignoring prepare conflicts, then this definitely indicates an error.
         std::vector<IndexKeyDatum>::iterator keyDataIt;
         if (member->getState() == WorkingSetMember::RID_AND_IDX &&
+            opCtx->recoveryUnit()->getPrepareConflictBehavior() ==
+                PrepareConflictBehavior::kEnforce &&
             (keyDataIt = std::find_if(member->keyData.begin(),
                                       member->keyData.end(),
                                       [currentSnapshotId = opCtx->recoveryUnit()->getSnapshotId()](