Repository navigation
Add configurable reconnection backoff for persisted peers #918
Description
Following #895 , peers are now retained in the store after force-closes so the background reconnection task can drive channel_reestablish recovery. The reconnection loop currently calls connect_peer_if_necessary on a fixed interval with no backoff, so a persisted-but-unreachable peer is retried at the same cadence indefinitely — log spam and wasted work, and now more visible because retained force-closed peers may never come back.
Proposed approach
Track per-peer failure state and apply exponential backoff, capped at a max. Roughly:
ruststruct PeerReconnectState { consecutive_failures: u32, next_retry_at: Instant, }
with a base/max interval and a next_backoff(failures) that doubles up to the cap. Modeled on the bitcoind RPC backoff approach in #588.
Open questions
Should trusted peers (trusted_peers_0conf) get a shorter max backoff, since reestablish latency matters more for them?
Should the retry state live inside ConnectionManager, or alongside PeerStore?
Happy to put up a PR once there's agreement on the boundary.
Activity
connection: per-peer exponential reconnection backoff
Jolah1 commentedon Jun 26, 2026
Opened #951 to implement this. It adds per-peer exponential backoff: each consecutive reconnect failure doubles the wait (starting at the existing 60s
PEER_RECONNECTION_INTERVAL) up to a 30-minute cap, and the state resets on a successful connect, an explicitdisconnect(), an inbound reconnection, or when the peer is removed after its last channel closes.One open question for reviewers: the title says "configurable" — the PR currently keeps the base interval and cap as crate constants to match the existing reconnection-interval constant, rather than exposing them on
Config. Happy to addConfigfields if that's preferred.It's marked draft because it depends on #895 (peer-removal relocation); I'll rebase and un-draft once that merges.
connection: per-peer exponential reconnection backoff
connection: per-peer exponential reconnection backoff
connection: per-peer exponential reconnection backoff
tnull commentedon Jul 14, 2026
As mentioned elsewhere, I'm not quite convinced this is a huge issue right now that's worth fixing and/or taking on additional complexity. A better way to solve this would probably also be to simply wait until the peer reconnected once before dropping it, which I now opened over at #983
Jolah1 commentedon Jul 15, 2026
noted.
Jolah1 commentedon Jul 16, 2026
Closing this: #983 (merged) addresses the case that motivated the issue — force-closed peers are no longer retained indefinitely, so there's no longer a class of peers that gets retried forever.
For the remaining case (a temporarily unreachable persisted peer being retried at a fixed 60s cadence), I agree the extra state tracking isn't justified right now. Can revisit if the retry churn shows up as a real problem in practice.