Details
-
Bug
-
Resolution: Duplicate
-
Major - P3
-
None
-
7.0.0, 7.2.0-rc0, 7.3.0-rc0
-
None
-
None
-
Catalog and Routing
-
ALL
-
2
Description
repro:
[direct: mongos] test> sh.shardCollection('test.foo', {x: 1}) |
{
|
collectionsharded: 'test.foo', |
ok: 1, |
'$clusterTime': { |
clusterTime: Timestamp(
|
{ t: 1700234597, i: 41 } |
),
|
signature: {
|
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0), |
keyId: Long("0") |
}
|
},
|
operationTime: Timestamp({ t: 1700234597, i: 41 }) |
}
|
[direct: mongos] test> db.createView('foo', 'bar', []) |
MongoServerError: got stale shardVersion response from shard _unknown_name_-rs0 at host ip-10-122-2-11:20000 :: caused by :: stale config in runCommand :: caused by :: timestamp mismatch detected for test.foo |
[direct: mongos] test> db.createView('foo', 'bar', []) |
MongoServerError: got stale shardVersion response from shard _unknown_name_-rs0 at host ip-10-122-2-11:20000 :: caused by :: stale config in runCommand :: caused by :: timestamp mismatch detected for test.foo |
_createView checks the shardVersion for the nss. In case the collection is sharded, we expect a shardVersion which is never present. The {create} command runs always against the primary shard and only carries the dbVersion. We should check that the namespace already exists before checking the version as already done for timeseries
Attachments
Issue Links
- duplicates
-
SERVER-82791 createView fails with StaleConfig if a sharded collection already exists with the same namespace
-
- Closed
-
- is caused by
-
SERVER-67633 Serialise explicit/implicit createCollection requests with sharded operations holding a RecoverableCriticalSection
-
- Closed
-