[bug]: node stops fetching blocks after losing its sync peer near tip; recovers only when a new peer connects #2606

Background

We run a mainnet btcd node behind a small public block explorer (https://btcd.watch). Twice in three days the node silently stopped following the chain: it stayed connected to all 8 outbound peers, logged nothing, and simply never fetched another block until we intervened by hand. Each time it sat 7–8 hours behind the network.

Both times, getpeerinfo showed no peer with syncnode: true, and both times the fix was to disconnect any one peer:

btcctl node disconnect <addr>:8333

Within a minute btcd connected a replacement peer, downloaded the missing headers, and resumed. No restart needed.

Timeline of the second incident (2026-09-11, UTC):

08:47:10 [INF] SYNC: Lost peer [2600:...]:8333 (outbound)
08:47:10 [INF] SYNC: New valid peer 81.107.181.46:8333 (outbound) (/Satoshi:31.1.0/)
08:47:16 [INF] SYNC: Lost peer 81.107.181.46:8333 (outbound)
08:49:16 [INF] SYNC: New valid peer 50.72.102.138:8333 (outbound) (/Satoshi:31.1.0/)
   ... nothing at all for 7h50m; getblockcount frozen at 966481, network reached 966527 ...
16:39:23 [INF] SYNC: Lost peer [2001:...]:8333 (outbound)            <- our manual "node disconnect"
16:39:24 [INF] SYNC: New valid peer 193.201.82.36:8333 (outbound) (/Satoshi:30.2.0/)
16:39:24 [INF] SYNC: Downloading headers for blocks 966482 to 966527 from peer 193.201.82.36:8333
16:39:24 [INF] SYNC: downloaded headers to ...(966527) from peer 193.201.82.36:8333 -- now fetching blocks
16:39:25 [INF] SYNC: Lost peer 193.201.82.36:8333 (outbound)
16:39:55 [INF] SYNC: New valid peer 209.126.10.240:8333 (outbound) (/Satoshi:29.0.0/)
16:39:55 [INF] SYNC: Syncing to block height 966527 from peer 209.126.10.240:8333
16:40:57 [INF] SYNC: Processed 2 blocks in the last 1m33.03s (height 966482, ...)

The first incident (2026-09-08, 17:35 UTC, ~7.5 h) looked the same: sync peer lost, "New valid peer", then silence, no syncnode peer, fixed by the same disconnect command. It happened on v0.26.0; we upgraded to v0.26.2 and it recurred.

What it looks like from the outside: once the node loses its sync peer while it is still a block or two behind, it stops reacting to the new-block announcements its peers keep sending, and it only wakes up when a new peer connects that advertises a higher height. Our host is slow on disk and is often a block or two behind, which probably makes us hit this more than most. Our own write-up with the code paths we believe are involved (in netsync/manager.go, around how ibdMode and syncPeer interact) is here: saubyk/btcd.watch#37 — happy to be corrected on that part.

Your environment

• btcd v0.26.2 (stock, built from tag with Go 1.26.4); previously v0.26.0, same behaviour
• Ubuntu Linux x86_64 VPS
• mainnet, txindex=1, addrindex=1, nolisten=1 (outbound peers only, default 8), utxocachemaxsize=450
• slow virtual disk: blocks often take 30–90 s to process at tip

Steps to reproduce

We can't trigger it on demand. Conditions both times: node at or within a couple of blocks of the tip, sync peer disconnects, no other peer is known to be ahead. From then on the node ignores new blocks until a fresh outbound connection is made. btcctl node disconnect on any peer reliably recovers it, which may help when trying to reproduce.

Expected behaviour

After losing its sync peer, btcd should keep accepting the new-block announcements it receives from its remaining peers, or re-elect a sync peer on its own. At minimum it should log that it is stuck.

Actual behaviour

btcd stays connected to all peers, logs nothing, reports no syncnode, and does not fetch new blocks for hours, until a new peer connection happens to be made. getblockchaininfo reports headers == blocks at the stale height, so nothing on the node itself indicates a problem.