|
SERVER-60144 added functionality to check the shard version of a time series collection by assigning the bucket NamespaceString to the operation sharding state, however, in a read path the following interleaving might happen:
- A sharded timeseries collection with namespace db.coll is created successfully
- A read comes into the shard for the timeseries collection and the shard role is set in the OperationShardingState, notice that because it is a timeseries, the namespace is transformed from db.coll to db.system.buckets.coll
- A drop collection and a shard collection gets executed, successfully dropping and creating a new sharded collection with namespace db.coll
- The read path continues, selecting a filtering phase
- When trying to obtain the ownership filter, we find that there is no shard version set for the collection db.coll in the operation context, so we fail the command with a tassert
Causing the read to fail. Usually on the find path, once it is detected the collection is actually a view (because timeseries collections are actually views), the read is transformed to an aggregation, but because a new sharded collection was created in step 3, the read continues as normal.
We should find a way to check the shard version in the read path, in order to determine whether the collection still exists before acquiring the lock free raii.
|