Fix peer selection bounds - #237
tolgahanbozkurt wants to merge 1 commit into
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe exponential peer picker now clamps its result to the last valid index. White-list selection passes the full filtered peer count to the picker and applies a separate cap to the retry-loop bound. ChangesPeerlist Selection
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to Peer selection now samples across the filtered candidates while keeping retries capped. The reviewed bounds have no concrete merge-blocking risk. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 1 system. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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. A rabbit checks the peerlist bounds, Comment |
Peer selection stops after three random draws because its draw limit is never updated from the filtered peer list. Duplicate or unavailable candidates can exhaust those draws before a usable peer is tried. The white-list selector also passes a last index to a helper that expects a count, excluding the final candidate. With two candidates, ordinary selection always picks the first.
Restore the bounded draw allowance and pass the full candidate count. Clamp the helper's result because floating-point rounding can reach its exclusive upper bound. The existing ten-entry limit, pruning and subnet preferences, bans, and failed-host cooldown remain in place.
Validated on an isolated Linux test server: the daemon builds with GCC 11 and passes an offline RPC startup check. All 57 focused checks using the actual selection functions with controlled peer lists and transport pass; the original code fails 15. The rounding case was also reproduced with the actual standard-library random distribution.