The applyOps path for dropIndexes makes an assertion that the primary does not. This can lead to a bug that generates an invalid oplog sequence and causes all secondaries to stop replicating.

There is a bug that can be described by the following sequence in its simplest form:

• Start building an index A
• dropIndexes aborts A and yields its locks
• Start building a new index build on A and commit
• Start building an index B
• dropIndexes reacquires its locks and sees that A is not in progress anymore, so it moves on to replicate a dropIndexes oplog entry instead.
• The secondary sees the dropIndexes oplog entry for A but blocks in the applyOps path because B is still in progress, something that did not happen on the primary.

We need to either a) assert on the primary that no index builds are in progress when a single index is dropped, or b) remove the assertion for the applyOps path.