-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
CAR Team 2025-12-08, CAR Team 2025-12-22
-
🟩 Routing and Topology
-
None
-
None
-
None
-
None
-
None
-
None
The router role loop is wrongly used by the refine_collection_shard_key_coordinator.cpp because the shards to be targeted are retrieved before entering the router role loop.
This is confussing because, in case of getting a StaleConfig error, the list of shards is never going to be updated.
Right now this is not a real problem because the list of shards is retrieved after a forced refresh, which guarantees that the ShardVersions won't be stale, along with the fact that migrations have been stopped.
The goal of this task is to make this code more robust by either:
- Either clarify through a comment that migrations must be stopped to ensure placement estability.
- Or, perform all the operations under the router role loop.
Â
If we go with the second option, we should get rid of the sharding_util::sendCommandToShardsWithVersion() method and replace it with  scatterGatherVersionedTargetByRoutingTable().
- is depended on by
-
SERVER-115323 Consider adding support for AsyncRPC in cluster_commands_helpers
-
- Needs Scheduling
-