SERVER-73532 added logic to invalidate the image collection during initial sync when the namespace is missing.
This logic unconditionally passes in true for upsertConfigImage on each write conflict retry attempt.
However, this can cause problems in cases like the following: consider an oplog batch containing two oplog entries requiring pre-images with the same LSID and these timestamps:
1. t1: {"t": 1686186824, "i": 50}
2. t2: {"t": 1686186824, "i": 54}
We can apply entries in a batch out of order, and so it's possible we apply entry 2 first. In that case, we will write an invalidate entry to the image collection for the LSID with timestamp t2.
Then, when we try to apply entry 1, we will query for an image collection entry with ts < t1.
We won't see one, and so we will attempt to insert such an entry, and get a duplicate key error, and retry indefinitely.
There is already logic in the code to handle this issue though. We can opt into it by pulling the boolean upsertConfigImage up out of the writeConflictRetry block so that we won't overwrite the value on retry attempts and will instead update rather than insert on retry.
See this comment for some additional context.
- is related to
-
SERVER-76774 Invariant that secondary oplog application doesn't get prepare conflicts
- Closed