Context

Before truncating anything in _reclaimOplogByTime(), we check that there is a valid truncate point using newestExpiredRecord(). newestExpiredRecord() accepts a mayTruncateUpTo RecordId argument. mayTruncateUpTo is calculated as

min(validAsOf, pinned oplog timestamp)

here.

Bug

If mayTruncateUpTo is null, meaning RecordId(0), we ignore it and truncate all records older than the oplog expiration time:

https://github.com/10gen/mongo/blob/master/src/mongo/db/storage/collection_truncate_markers.cpp?plain=1#L81-L85

    // it's OK to round off expiry time to the nearest second.
    RecordId seekTo(durationCount<Seconds>(expiryTime.toDurationSinceEpoch()), /* low */ 0);
    if (!mayTruncateUpTo.isNull() && seekTo > mayTruncateUpTo) {
        seekTo = mayTruncateUpTo;
    }
    record = cursor->seek(seekTo, SeekableRecordCursor::BoundInclusion::kInclude);
 

mayTruncateUpTo can be null when the pinned oplog timestamp has not been advanced or, after SERVER-131744, the validAsOf timestamp has not been persisted yet.

The result is we can truncate oplog before it has been persisted, which has caused AF-18740 and BF-44537.

Solution

Disallow any truncation in newestExpiredRecord() when mayTruncateUpTo is RecordId(0). This is the current behavior for size-based truncation.