-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Catalog and Routing
-
CAR Team 2024-11-25
-
2
The shard version {0,0} with a timestamp and an epoch indicates that a shard does not own any chunks for the specific collection. If this version is compared—either in the router role or the shard role—with another version, it can lead to misleading results because {0,0} is not comparable; it could be either newer or older than the version being compared.
Currently, this is not a problem in our code as we have correctly handled this edge case in all situations where shard versions are compared. However, we cannot guarantee that future usages will correctly compare the {0,0} shard version.
The existing API for comparing shard versions uses `olderThan`, which first addresses non-comparable versions and returns `false` if the versions in question are not comparable. Note that UNSHARDED and IGNORED shard versions are also not considered comparable.
This ticket aims to ensure that the shard version (epoch, timestamp, {0,0}) is treated as non-comparable and to guarantee that our API (currently `olderThan`) is not callable for non-comparable shard versions.
- is related to
-
SERVER-95979 Properly handle StaleConfig when wanted shard version is {0,0} in the router role
- Closed