Improve error semantics for ConnectionPool controllers' untracked pools

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Server Programmability
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Currently, we consider it a bug issue if a ConnectionPool::ControllerInterface implementation is asked to update state or provide information about a host that wasn't previously registered with the controller via addHost. Similarly, we consider it a correctness error if the same host was registered with the controller multiple times.

      In each case, we invariant in the controller when we detect this issue. However, the error likely originates not in the controller's maintenance of the maps, but in the calling-code that forgot to register a pool or registers the same one multiple times. Throwing an error and allowing the calling-code to handle it (including by possibly invarianting) would improve the readability + maintainability of the code, produce better/more descriptive errors, and would allow us to remove the use of the helpers getOrInvariant and emplaceOrInvariant and replace them with ordinary standard library container API calls.

            Assignee:
            Unassigned
            Reporter:
            George Wangensteen (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: