Operational Defect Database
BugZero found this defect 310 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
MongoDB | 2392379
Recreating a sharded timeseries collection as a sharded collection might lead to a read failure
Last update date:
3/14/2024
Affected products:
MongoDB Server
Affected releases:
5.0.0
6.0.0
6.3.2
7.0.0-rc7
Fixed releases:
No fixed releases provided.
Description:
Info
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.
Top User Comments
JIRAUSER1256927 commented on Wed, 8 Nov 2023 16:55:24 +0000: I believe that if we do first SERVER-80719 we might have a more general approach to tackle this problem.
Steps to Reproduce
Apply the attached patch in revision 107f24c Compile the server Run the test using the sharding suite: python ./buildscripts/resmoke.py run --suites=sharding ./jstests/sharding/test_find_classical_with_concurrent_drop.js --log=file
