-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
200
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).
This ticket is to consider making this pattern a common utility that can be reused wherever needed.
- is depended on by
-
SERVER-79997 In attachCursorToPipeline when local read fails we should not catch stale config exceptions
- Backlog
- is related to
-
SERVER-82860 Local data access for aggregations should not keep retrying in case of StaleConfig
- Closed
-
SERVER-94502 Nesting shard role into router role breaks collection metadata recovery
- Closed
-
SERVER-85941 Improve discovery of routing information for views
- Open