-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
🟩 Routing and Topology
-
None
-
None
-
None
-
None
-
None
-
None
It was raised during this code review that the api around shard retry policies could be made more readable and more understandable simply by renaming them.
I think since the meaning of some of those retry policies changed during the execution of SPM-4003 we should give proper thoughts to the names of those retry policies to make it clear to the reader what is the condition for which we retry.
This refactor should be safe and easy to conduct.
- related to
-
SERVER-111380 Investigate if kNotIdempotent and kStrictlyNotIdempotent retry policies can be merged
-
- Open
-