fix(eth/downloader): include xdc164 peers in idle peer selection#2491
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Fixes a downloader peer-selection regression where the idle peer selectors (used for concurrent header/body/receipt/state downloads) could exclude newer protocol versions (xdc/164), causing sync to stall with errPeersUnavailable once the network upgrades.
Changes:
- Introduce a
maxProtocolVersionceiling (set to164) and use it in idle peer selection. - Expand
HeaderIdlePeers,BodyIdlePeers,ReceiptIdlePeers, andNodeDataIdlePeersto include xdc/164 peers. - Add a regression test to ensure peers across supported protocol versions are considered eligible for idle selection.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| eth/downloader/peer.go | Replaces hardcoded protocol version ceilings in idle peer selection with a single maxProtocolVersion constant. |
| eth/downloader/peer_test.go | Adds a regression test ensuring idle peer selectors return peers across protocol versions. |
Comments suppressed due to low confidence (1)
eth/downloader/peer.go:498
- BodyIdlePeers now filters out eth/62 peers by setting minProtocol=63, even though body fetching supports v62 (FetchBodies checks p.version < 62). Keep the lower bound at 62 to avoid needlessly excluding compatible peers.
return ps.idlePeers(63, maxProtocolVersion, idle, throughput)
The xdc/164 protocol (EIP-2364 handshake) was added without updating the idlePeers version ceiling, which was still capped at 101 from the xdc100 era. Once all peers negotiate version 164, HeaderIdlePeers, BodyIdlePeers, ReceiptIdlePeers and NodeDataIdlePeers return empty sets, so fetchParts aborts every skeleton/body/receipt/state fetch with errPeersUnavailable (surfacing as "retrieved hash chain is invalid: no peers available or all tried for download"). Any node falling more than a few blocks behind can then never sync again. Replace the hardcoded ceilings with a maxProtocolVersion constant covering xdc164 and add a regression test asserting that peers of every supported protocol version are eligible for concurrent downloads.
Proposed changes
This PR fixes the bug: "no peers available or all tried for download" which is introduced in #2470 and cause network stuck.
The xdc/164 protocol (EIP-2364 handshake) was added without updating the idlePeers version ceiling, which was still capped at 101 from the xdc100 era. Once all peers negotiate version 164, HeaderIdlePeers, BodyIdlePeers, ReceiptIdlePeers and NodeDataIdlePeers return empty sets, so fetchParts aborts every skeleton/body/receipt/state fetch with errPeersUnavailable (surfacing as "retrieved hash chain is invalid: no peers available or all tried for download"). Any node falling more than a few blocks behind can then never sync again.
Replace the hardcoded ceilings with a maxProtocolVersion constant covering xdc164 and add a regression test asserting that peers of every supported protocol version are eligible for concurrent downloads.
Types of changes
What types of changes does your code introduce to XDC network?
Put an
✅in the boxes that applyImpacted Components
Which parts of the codebase does this PR touch?
Put an
✅in the boxes that applyChecklist
Put an
✅in the boxes once you have confirmed below actions (or provide reasons on not doing so) that