Renames across databases currently always follow this lock ordering:

• Lock source database in MODE_IX
• Lock source collection in MODE_S
• Lock target database in MODE_X

This has the potential to deadlock operations on the source database indefinitely if the following interleaving occurs with two simultaneous renames across the databases:

• Op1 locks dbA in MODE_IX
• Op1 locks collA in MODE_S
• Op2 locks dbB in MODE_IX
• Op2 locks collB in MODE_S
• Op1 now waits until dbB can be locked in MODE_X
• Op2 now waits until dbA can be locked in MODE_X

Both operations are now interlocked and will never make forward progress. This has the unfortunate side effect that all other CRUD operations on dbA and dbB cannot make forward progress since the MODE_X locks are enqueued before them which will never be granted.

The same issue is happening on renameCollectionForApplyOps. As they will take the locks in the order of source followed by target.