There is a test failure where:
- an initial syncing node starts an index build
- then initial sync fails
- initial sync restarts, dropping all the replicated databases again before starting cloning again
- and a drop collection runs into an index build in progress invariant
The codepath for hitting the invariant is coming through:
- InitialSyncer::_truncateOplogAndDropReplicatedDatabases
- StorageInterfaceImpl::dropReplicatedDatabases
- DatabaseHolderImpl::dropDb
- invariantFailedWithMsg
DatabaseHolderImpl::dropDb technically expects the caller to have checked for in-progress index builds before calling, which didn't happen. I suppose initial sync finding an index build in-progress at a higher level is also an invariant'ing offense. Maybe think about it a bit more whether some higher level invariant about no index builds in progress should be added, or not.