net: fix four ways IBD can stall

[niteshbalusu11]

Summary

Four bugs can stop IBD from making progress. Each fix is small.

 header cache cleanup
-  drop height/parent of headers outside the live window
+  keep them while the header is stored on the path and waiting to be queued

 header intake
+  skip a new lookahead header that would jump past the next path height

 peer recovery
-  count every empty reconnect round; give up after the limit,
-  even while a new connection is still starting
+  count only empty rounds with no live peer; stop new dials after the limit
+  wait for a connection that already started, then give up

 peer rate limit (tip-follow session)
-  drop the over-budget message and keep reading
+  disconnect, so the dropped block request is asked again right away
+  a second rate-limit disconnect from the same address within an hour
+  discourages it for a day (like two overflows in one session did)
+  noban, manual, and loopback peers leave no strike

 follow session end (return or abort by disconnectnode / eviction)
+  release the session's unanswered block asks, so other peers can fetch them

Evidence

• Before: each new test fails without its fix:

  • drained_queue_refills_stored_headers_after_known_header_pruning
  • new_lookahead_batch_does_not_skip_stored_queue_successors
  • redial_budget_spends_only_dark_empty_rounds_and_waits_out_a_started_dial (old rule: an empty top-up with a live peer spent the budget, got 4, want 0)
  • rate_limited_block_request_disconnects_without_waiting_for_another_message
  • second_rate_limit_disconnect_from_an_address_discourages_it (second disconnect did not refuse the address)
  • exempt_peer_rate_limit_leaves_no_strike_on_its_address (a manual peer's strike made the next ordinary peer's first overflow a refusal)
  • closed_follow_session_releases_its_block_asks (the ask was still held after the session ended)
  • aborted_follow_session_releases_its_block_asks (the ask was still held after disconnect_id aborted the session)

  After: all pass. fmt, clippy, deny, ast-grep, and os-smoke pass locally. Workspace tests pass except three that also fail on master on this Mac (socket FIN timing, 127.0.0.2 bind, end_of_ibd_sh_interrupt).

• Before: signet IBD from one local peer on 38f419b9: stuck at height 69,190 for 6+ minutes (headers stored=0 queue=1, peer alive). Never recovered.

  After: a build with this fix synced to 326,785 and went ready. That build also had unrelated perf commits; a run of this branch alone will follow in a comment.

Merge Danger

Door: two-way

Revert the commits to go back. No schema or on-disk change.

Blast Radius: IBD and tip-follow peers

IBD header queueing and peer recovery change. On the tip-follow session, a peer over the rate budget is now disconnected on the first overflow, not the second. The budgets are unchanged. A repeat from the same address within an hour still discourages it for a day. Noban, manual, and loopback peers leave no strike. Strikes are in memory only and capped like the discouraged set.

🤖 Generated with Claude Code

[niteshbalusu11]

Signet run of this branch alone (189fa4d6), one local peer, same setup as the stall above: synced to 326,785 in 654 s and went ready. Tip hash matches the peer. No stall.

[rearden-grok]

Summary

The header-cache retain and the contiguous-enqueue check fix real stalls, and their tests go through hygiene / apply rather than a detached helper. The redial split is also right: an in-flight dial is bounded by connect_timeout, empty rounds no longer abort it, and a fully dark budget still stops new dials and then GiveUpMidCatchup. The rate-limit change does not. It disconnects the follow session on the first over-budget frame without discouraging the address and without releasing asked_blocks, so a dropped body ask is pinned instead of retried. The four changelog fragments also omit the category line release-cut requires.

Issue counts by severity

• bugs: 2
• suggestions: 1
• nits: 0

[rearden-grok]

Summary

The three earlier findings are fixed on the paths they named. A first application-frame overflow now returns through rate_limit_disconnect, a second strike from that address calls threshold_disconnect (and spawn_inbound_accept refuses the next inbound via inbound_discouraged), and the asked_blocks drain sits after the select so that return releases the session's asks. The changelog is one Fixed fragment, and ibd_cancellable spends the dark budget only through dark_empty_after / may_spawn_redial (exactly four fully dark empty dials, then give up once that dial has finished). Two holes remain: the strike is recorded before the noban/manual/loopback checks, and disconnect_id aborts the session task so the new drain never runs.

Issue counts by severity

• bugs: 2
• suggestions: 1
• nits: 0

[niteshbalusu11]

@rearden-grok please re-review the latest commits.

[rearden-grok]

Summary

Both bugs from the last review are fixed, and the rate-limit comment now matches the return. refusable_addr is applied before note_rate_strike, so a noban, manual, or loopback overflow still disconnects with Protocol("peer rate limit") and leaves no strike; a normal address strikes once and the next overflow discourages through threshold_disconnect. SessionFollow lives on the peer_session_with task that disconnect_id aborts, and its Drop is the only ask drain, so a normal return and an abort both release requested_blocks (compact and getblocktxn asks included). No new defect in this delta.

Issue counts by severity

• bugs: 0
• suggestions: 0
• nits: 0