-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
200
-
None
-
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).
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
-