-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 7.0.0, 7.2.0-rc0, 7.3.0-rc0
-
Component/s: None
-
None
-
Catalog and Routing
-
ALL
-
2
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
- 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