Scenario

1. Sharded cluster. A sharded collection db.foo exists with UUID existingUuid and epoch existingOid.
2. A createIndexes call is sent to the cluster.
3. The first attempt at creating an index fails on the shard due to a transient error.
4. Before the shard starts the second attempt, another thread on the same shard drops db.foo.
5. On the second attempt, the createIndexes call will see that the collection doesn't exist, and will implicitly create db.foo, unsharded, with UUID generatedUuid.
6. The createIndexes command will succeed, with the requested indexes on the newly created db.foo.

This is incorrect behavior – the createIndexes call should see that the collection was dropped somehow and should fail the createIndexes call permanently.

Proposed Solution

Place a call to csr->checkShardVersionOrThrow() in a new function OpObserverShardingImpl::shardObserveCreateIndexes. This call will see that the newly created collection does not have epoch existingOid (because the collection is now unsharded), and will fail the operation.

Open Questions

1. Will failing the createIndexes call at the point of the opObserver roll back the implicit collection creation?