per @nothingmuch, removing the cli RelayManager (#1696) needs a replacement that remembers relay failures across sessions. a durable, stateful counterpart to the stateless retry policy in #1670, and separate from selection.
RelaySelector (#1694) tracks failed relays in memory per operation only; nothing persists, so clients re-try long-dead relays on every fresh run.
gap:
- failure state is ephemeral (per-call
RelaySelector); nothing records which relays are persistently unreachable (relay-scoped transport failures, not directory faults)
- a mobile app that wakes up next month still contacts relays that went down long ago and are still in config
- no notion of failure rate over time to decide when to give up on a relay
open questions:
- what failure-rate metric, over what window, marks a relay dead and how is that persisted?
- when is a relay "down for good" (give-up threshold), and is there a path back (re-test recovery)?
- a relay whose IP/domain may have been taken over: stop using it even while it's still configured?
- lib-side trait the integrator implements, or fully integrator-side filtering that feeds a pre-filtered list into
RelaySelector?
related: #1670 / #1694 / #1696 / #1586
per @nothingmuch, removing the cli
RelayManager(#1696) needs a replacement that remembers relay failures across sessions. a durable, stateful counterpart to the stateless retry policy in #1670, and separate from selection.RelaySelector(#1694) tracks failed relays in memory per operation only; nothing persists, so clients re-try long-dead relays on every fresh run.gap:
RelaySelector); nothing records which relays are persistently unreachable (relay-scoped transport failures, not directory faults)open questions:
RelaySelector?related: #1670 / #1694 / #1696 / #1586