Skip to content

Add configurable reconnection backoff for persisted peers #918

@Jolah1

Description

@Jolah1

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions