Consider renaming retry policies to convey their meaning better

    • 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.

            Assignee:
            Unassigned
            Reporter:
            Guillaume Racicot
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: