peer selection - backoff when no peers available

[freemans13]

Summary

• Add backoff mechanism to selectAndActivateNewPeer() to prevent busy-loop when peer selection fails

Problem

When selectAndActivateNewPeer() (called from handleRunningState()) fails to find a suitable sync peer, it simply returns without any backoff. This path runs every 2 seconds via the FSM monitor, and when all peers fail selection (e.g., health checks fail, all on cooldown), it creates a tight loop of:

1. Check FSM state → RUNNING
2. Call selectAndActivateNewPeer()
3. All peers fail selection (health checks, cooldown, etc.)
4. Return immediately
5. Wait 2 seconds, repeat

Each iteration involves expensive health check HTTP requests for every peer.

Solution

1. Add SyncAttemptCooldown to selection criteria - Makes selectAndActivateNewPeer() consistent with selectNewSyncPeer(), which already uses a 1-minute cooldown. Without this, peers could be retried immediately through this code path.

2. Call enterBackoffMode() when no peer found - When peer selection fails (either no eligible peers or selector returns empty), enter exponential backoff. This uses the existing backoff mechanism (2s, 4s, 8s, etc.) to prevent hammering peers when none are available.

Test plan

• Verified reduced CPU usage when all peers fail selection
• Existing tests pass
• Lint passes

🤖 Generated with Claude Code

[github-actions]

🤖 Claude Code Review

Status: Complete

Summary: The changes look good and directly address the busy loop issue when no eligible peers are available. The addition of enterBackoffMode() calls at both decision points ensures the system backs off instead of repeatedly attempting peer selection.

Analysis:

• Line 435: Added backoff when no eligible peers exist (banned, low reputation, etc.) - prevents immediate retry
• Line 442: Added SyncAttemptCooldown: 1 * time.Minute - consistent with line 254 pattern
• Line 451: Added backoff when peer selection fails (health checks, cooldown) - prevents tight loop

The backoff implementation is already present in the codebase (lines 669-688) with exponential backoff and peer attempt clearing, making this a straightforward fix to invoke it at the right points.

No issues found - the implementation correctly prevents CPU-intensive busy loops while maintaining sync functionality.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud