I was looking at how we make createCollection idempotent for oplog application. In the case there is a conflicting collection with the same namespace, we would rename the existing collection (newCollName) to a temporary collection (tmpName). But renameCollection requires a MODE_X lock on both the fromNss and the toNss. But based on what I saw in createCollectionForApplyOps, I don't see how we could hold a MODE_X lock on newCollName . Same for this rename. I don't see necessary locks being acquired in this function.

I initially suspected this was a bug. But actually we won't hit the locking invariants in renameCollection because because isCollectionLockedForMode always returns true when !shouldConflictWithSecondaryBatchApplication(). And currently, the oplogApplier always sets shouldConflictWithSecondaryBatchApplication to false. If this is the assumption we need for calling createCollectionForApplyOps, we should add an invariant.

The locking invariants in renameCollection were hit during tenant migrations. Tenant migration is similar to initial sync but it applies oplog entries on the primary node. So we don't set shouldConflictWithSecondaryBatchApplication to false like we do for normal replication. To work around the invariants mentioned above and unblock tenant migration, we could make tenant migration set shouldConflictWithSecondaryBatchApplication to false. But I think createCollectionForApplyOps should probably acquire the necessary locks on its own. So this is a ticket for that investigation and I am not sure if this would be a bug for applyOps (maybe not because applyOps takes global X lock for commands?).