Our ClientPool rotation handling within runLoop pessimistically assumes that any client start is after a failure and always attempts to replayListenAddresses despite the original calls into ListenAddresses having just successfully completed. This causes our pool startup to broadcast listen addrs twice on first start.
In order to be more bandwidth efficient, we should find a way to detect whether we're recovering from a failure or not as part of our runLoop.
Our ClientPool rotation handling within
runLooppessimistically assumes that any client start is after a failure and always attempts to replayListenAddresses despite the original calls into ListenAddresses having just successfully completed. This causes our pool startup to broadcast listen addrs twice on first start.In order to be more bandwidth efficient, we should find a way to detect whether we're recovering from a failure or not as part of our runLoop.