Background
We're currently debugging an RPC issue, but our logs are spammed with the following message since one peer is also down (independent of the third-party RPC failure)
2026-08-05T11:14:53.283101028Z 2026-08-05T11:14:53.282939Z INFO mpc_node::p2p: could not connect, retrying my_id=8 target_participant_id=13 error=failed to establish tcp stream: Connection refused (os error 111)
We should use exponential backoff for outbound connection retries imo, so we don't constantly hammer peers and spam our logs when a node is down.
User Story
As a node operator I want clean logs and no needless spamming of reconnect attempts.
Acceptance Criteria
We use exponential backoff in our reconnection attempts for offline peers.
Resources & Additional Notes
No response
Background
We're currently debugging an RPC issue, but our logs are spammed with the following message since one peer is also down (independent of the third-party RPC failure)
We should use exponential backoff for outbound connection retries imo, so we don't constantly hammer peers and spam our logs when a node is down.
User Story
As a node operator I want clean logs and no needless spamming of reconnect attempts.
Acceptance Criteria
We use exponential backoff in our reconnection attempts for offline peers.
Resources & Additional Notes
No response