Conversation
📝 WalkthroughWalkthroughThe pull request modifies peer address handling throughout the network module, changing the internal API to work with Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
dash-spv/src/network/manager.rs (1)
1252-1258:⚠️ Potential issue | 🟠 Major
shutdown()still usesget_addresses_for_peer(MAX_ADDR_TO_STORE)— same cap bug persists here.The maintenance loop (line 889) was fixed to use
get_known_addresses(), butshutdown()still callsget_addresses_for_peer(MAX_ADDR_TO_STORE)which internally caps the result toMAX_ADDR_TO_SEND(line 102 inaddrv2.rs). Since shutdown is the last chance to persist peers, this is arguably the most important call site to fix.Proposed fix
- let addresses = self.addrv2_handler.get_addresses_for_peer(MAX_ADDR_TO_STORE).await; + let addresses = self.addrv2_handler.get_known_addresses().await;
We currently fetch peers to store via
get_addresses_for_peer(MAX_ADDR_TO_STORE)which caps the number internally toMAX_ADDR_TO_SEND. Its not a problem really right now since we so far not even close to end up with so many peers because peer discovery isn't functional but its still wrong.get_known_addressesto return the fullAddrV2Messageinstead of just theSocketAddr.get_known_addressesfor peer saving.Working towards closing:
Summary by CodeRabbit
Release Notes
Refactor
Tests