-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
Fully Compatible
-
CAR Team 2025-10-13, CAR Team 2025-10-27
-
200
-
🟦 Shard Catalog
-
None
-
None
-
None
-
None
-
None
-
None
The concept of "ShardRole retry loop" (i.e. execute something and if it throws due to this shard having stale/unknown sharding metadata then refresh and try again) is present in several places throughout the code. Examples of this are service_entry_point, resharding_data_copy_util or ttl.cpp (this last one may be a stretch since the refresh is asynchronous and there's not retry at this level).
SERVER-112449 will make this a common utility that can be reused wherever needed.
This ticket is to replace the existing instances of this pattern with the proposed unified utility.
- fixes
-
SERVER-90503 Investigate if we can or cannot retry a getMore command after getting a StaleDbVersion in the shard
-
- Closed
-
-
SERVER-90504 Investigate if we can retry the command after getting a stale exception because the shard is in the critical section
-
- Closed
-
- has to be done after
-
SERVER-112449 Create ShardRole retry loop utility
-
- Closed
-
- is depended on by
-
SERVER-79997 In attachCursorToPipeline when local read fails we should not catch stale config exceptions
-
- Closed
-
- is related to
-
SERVER-94502 Nesting shard role into router role breaks collection metadata recovery
-
- Closed
-
-
SERVER-85941 Improve discovery of routing information for views
-
- Open
-
- related to
-
SERVER-113274 Increase min config fuzzer limit for the maxShardStaleMetadataRetryAttempts parameter
-
- Closed
-