When we acquire collection locks with AutoGetCollectionForRead, we set the TimestampReadSource on the recovery unit based on whether we were a primary or a secondary at the time. However, when we re-acquire locks after a yield in PlanExecutor, we use the same TimestampReadSource we had when we originally acquired those locks. Since reads survive replication state changes, that can result in a read on the primary using the lastApplied read source, or a read on the secondary using noTimestamp read source. The latter can result in us reading from within the middle of a replication batch, which means reading possibly causally-related data out of order. The former is bad for the oplog specifically, because on a primary, the lastApplied time is not oplog-hole-free, meaning we can read past oplog holes.