fix(dash-spv): replaced TARGET_PEERS with already existing max_peers config fields#827
fix(dash-spv): replaced TARGET_PEERS with already existing max_peers config fields#827ZocoLini wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughRemoves the fixed Configurable peer limit
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #827 +/- ##
==========================================
- Coverage 73.18% 73.18% -0.01%
==========================================
Files 323 323
Lines 72295 72300 +5
==========================================
+ Hits 52911 52913 +2
- Misses 19384 19387 +3
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@dash-spv/src/network/pool.rs`:
- Around line 24-28: PeerPool::new currently allows max_peers to be zero, which
makes the pool permanently behave as full and breaks add_peer, needs_more_peers,
and can_accept_peers. Update the PeerPool::new constructor to enforce the
invariant that max_peers is at least 1, mirroring the clamping already done in
manager.rs, so callers of PeerPool::new cannot create an unusable pool.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 61770d09-2eec-422d-b7ed-1eb571ba9c76
📒 Files selected for processing (5)
dash-spv/src/network/constants.rsdash-spv/src/network/manager.rsdash-spv/src/network/pool.rsdash-spv/src/network/tests.rsdash-spv/tests/peer_test.rs
💤 Files with no reviewable changes (1)
- dash-spv/src/network/constants.rs
| pub fn new(max_peers: usize) -> Self { | ||
| Self { | ||
| peers: Arc::new(RwLock::new(HashMap::new())), | ||
| connecting: Arc::new(RwLock::new(HashSet::new())), | ||
| max_peers, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Enforce the max_peers >= 1 invariant in PeerPool::new.
Line 121 in dash-spv/src/network/manager.rs already clamps the config to at least 1, but the public pool constructor does not. PeerPool::new(0) now creates a pool that can never accept a peer because add_peer, needs_more_peers, and can_accept_peers all immediately behave as if the pool is full.
Suggested fix
pub fn new(max_peers: usize) -> Self {
Self {
peers: Arc::new(RwLock::new(HashMap::new())),
connecting: Arc::new(RwLock::new(HashSet::new())),
- max_peers,
+ max_peers: max_peers.max(1),
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pub fn new(max_peers: usize) -> Self { | |
| Self { | |
| peers: Arc::new(RwLock::new(HashMap::new())), | |
| connecting: Arc::new(RwLock::new(HashSet::new())), | |
| max_peers, | |
| pub fn new(max_peers: usize) -> Self { | |
| Self { | |
| peers: Arc::new(RwLock::new(HashMap::new())), | |
| connecting: Arc::new(RwLock::new(HashSet::new())), | |
| max_peers: max_peers.max(1), |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@dash-spv/src/network/pool.rs` around lines 24 - 28, PeerPool::new currently
allows max_peers to be zero, which makes the pool permanently behave as full and
breaks add_peer, needs_more_peers, and can_accept_peers. Update the
PeerPool::new constructor to enforce the invariant that max_peers is at least 1,
mirroring the clamping already done in manager.rs, so callers of PeerPool::new
cannot create an unusable pool.
1 participant
Summary by CodeRabbit