|
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.
|