Follow-up from PR #909 review.
Hive sync test 285 exposed that blocks_by_root peer selection can pick a connected peer whose latest Status reports head_slot=0, even when the requested root is for a block at slot N>0. PR #909 tactically pins checkpoint parent walks to the peer that just served the prior status/chunk, but the broader fix should make peer selection slot-aware.
Proposed direction:
- Add a
min_slot / requested-slot hint to blocks-by-root peer selection.
- Filter candidates whose latest known
Status.head_slot < min_slot.
- Treat unknown status carefully (probably allowed only when no status-aware candidate exists, or after explicit policy decision).
- Mirror LeanSpec's
PeerManager.select_peer_for_request(min_slot=...) behavior.
This should cover gossip/cached-descendant parent fetches too, not only checkpoint-sync walks.
Context: #909 (review)
Follow-up from PR #909 review.
Hive sync test 285 exposed that
blocks_by_rootpeer selection can pick a connected peer whose latest Status reportshead_slot=0, even when the requested root is for a block at slot N>0. PR #909 tactically pins checkpoint parent walks to the peer that just served the prior status/chunk, but the broader fix should make peer selection slot-aware.Proposed direction:
min_slot/ requested-slot hint to blocks-by-root peer selection.Status.head_slot < min_slot.PeerManager.select_peer_for_request(min_slot=...)behavior.This should cover gossip/cached-descendant parent fetches too, not only checkpoint-sync walks.
Context: #909 (review)