If there are two concurrent "dropIndexes" commands on a collection (one on each index A and B), this can lead to the following order of operations on the secondary:

• startIndexBuild A
• startIndexBuild B
• commitIndexBuild A
• dropIndexes A -> blocks due concurrent index build B
• abortIndexBuild B -> never reached due to blocking previous operation (from a separate dropIndexes command)

The blocking is caused by the assertion that no background operations are in progress when processing the dropIndexes oplog entry for "a_1". This throws and blocks oplog application. dropIndexesForApplyOps assumes that no background operations are in progress, which is not always the case. The non-applyOps version of dropIndexes has a similar assertion which only gets executed when no index builds were aborted.

What I think might be the root causes of this failure:

• An index can be reported as aborted if even when it has already committed
• This bypasses this assertion on the primary, but hits this assertion on the secondary, leading to this deadlock.