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.
- is depended on by
-
SERVER-46594 Enable commit quorum for concurrency suites.
- Closed
- related to
-
SERVER-46595 createIndexes command fails to abort index build when interrupted
- Closed