Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
The following fails for me every time on 7.1.0-alpha0-201-g1eb2c72: db = db.getSiblingDB("mytest") db.dropDatabase() db.createCollection( "weather", { timeseries: { timeField: "mytimefield", }, }, ) db.getSiblingDB("admin").runCommand( { shardCollection: db.getName() + `.weather`, key: { mytimefield: 1, }, }, ) db.createCollection( "weather", { timeseries: { timeField: "mytimefield", }, }, ) The failure is: MongoServerError: got stale shardVersion response from shard src-sh02 at host localhost:28022 :: caused by :: timestamp mismatch detected for TestE2EIntegrationTestSuite_TestTimeSeries_Sha-8120c373cd712241.system.buckets.weather In v7.0.1 the error is less serious-looking: MongoServerError: namespace mytest.weather already exists, but is a view on mytest.system.buckets.weather rather than mytest. In v6.0.9 the error also looks wrong: MongoServerError: ns: mytest.weather already exists with different options: { timeseries: { timeField: "mytimefield", granularity: "seconds", bucketMaxSpanSeconds: 3600 } } I would expect there to be no error since I’m just creating the existing collection. The 7.1.0 error looks worst, followed by 6.0.9, then 7.0.1.
xgen-internal-githook commented on Wed, 11 Oct 2023 14:41:11 +0000: Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'} Message: SERVER-80776 Prevent `StaleConfig` on time-series creation Branch: master https://github.com/mongodb/mongo/commit/5f753b64500373a5a36acefd4c9867a3aafc187c gregory.noma commented on Fri, 22 Sep 2023 18:53:45 +0000: On v7.1, the error that gets returned back to the user looks like this: "ok" : 0, "errmsg" : "got stale shardVersion response from shard shard-rs1 at host localhost:20001 :: caused by :: timestamp mismatch detected for timeseries_create.system.buckets.timeseries_0", "code" : 13388, "codeName" : "StaleConfig", "ns" : "timeseries_create.system.buckets.timeseries_0", "vReceived" : { "e" : ObjectId("000000000000000000000000"), "t" : Timestamp(0, 0), "v" : Timestamp(0, 0) }, "vWanted" : { "e" : ObjectId("6508b89b93d09586582b184e"), "t" : Timestamp(1695070363, 24), "v" : Timestamp(1, 0) }, "shardId" : "shard-rs1", "$clusterTime" : { "clusterTime" : Timestamp(1695070363, 46), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1695070363, 46) It looks like this strange error is a result of SERVER-76547, in particular this usage of acquireCollectionMaybeLockFree that was added. I believe this is because when the create command is forwarded from the router to the shard, it contains the shard versioning information for the user-facing time-series view namespace, which is unsharded. But then this collection acquisition is on the underlying buckets collection, which is sharded. Thus we end up with this StaleConfig error.
Run the above script, e.g., with `mongosh`.