[v8.0 only]

Summary

There is a window of time while we commit the drop of a collection to WiredTiger where we expose the collection without any indexes (neither user created indexes nor the required _id index) to concurrent readers. This is inconsistent with drop being atomic (should always expose either the collection with indexes, or nothing).

The impact is that concurrent readers may see a Collection instance without indexes, so:

• They may fail, crash, or otherwise act incorrectly as they expect the _id index to be present (SERVER-130823's tassert is likely caused by this).
• They may decide to run some expensive query plan, e.g. COLLSCAN, since they do not see the previously existing indexes yet they can see the collection's documents.

Technical detail

This happens as follows:

• As part of the drop, we create an in-memory non-durable clone of the Collection instance where we drop all indexes (so the non-durable clone has 0 indexes).
• The drop creates a kDroppedCollection CollectionCatalog action (with the non-durable clone in the "dropped collection" field), and commits the atomic collection+indexes drop to storage (WiredTiger).
• When WiredTiger informs us that the drop is committed, the kDroppedCollection action places the non-durable clone in the _dropPendingCollection set.
• This clone has a very short lifetime as it's backed by a weak_ptr associated to the drop operation. However it's possible that we immediately serve it to a concurrent reader (e.g. one reading at a point in time before the drop) since establishConsistentCollection looks into the _dropPendingCollection set.

A reproducer is attached.

Proposed fix

establishConsistentCollection should not return the instance in _dropPendingCollection since it's not consistent and doesn't correspond to any persisted durable catalog state.

Affected versions

The affected code doesn't exist in v7.0.

In v8.3+, the affected code was removed by SERVER-107956.

Therefore v8.0 is the only supported affected version.