An invariant can fail in dropIndexes given the following sequence between command threads A, B, and C:

• A: Start an index build on {a: 1}
• B: dropIndexes: {a: 1}
  • Aborts the active index build
• C: Start and finish another index build on {a: 1}
• B: dropIndexes does not retry aborting because it sees no active index build
  • invariant fails because the {a: 1} index is completed even though it was successfully aborted 
  • This is because an index by the same name was able to start and commit after waiting for the build to complete and before retaking the collection X lock.

Part of the problem here is that index names are not unique to index builds, so while the dropIndexes command can successfully abort an index build, another index by the same name could be created again in a brief window of time before it reacquires its locks.

In this scenario, we should consider dropping the finished index if we discover that it exists.  This was the previous behavior.