Fix rebroadcast capacity check with no peers#5055
Fix rebroadcast capacity check with no peers#5055pwojcikdev merged 1 commit intonanocurrency:developfrom
Conversation
Treat an empty network as having available capacity so rebroadcasting does not fail early when no channels exist. Relax the rebroadcaster test to accept multiple queued events instead of assuming the counter stays exactly at one.
10294fb to
8df578a
Compare
Test Results for Commit 8df578aPull Request 5055: Results Test Case Results
Last updated: 2026-03-30 21:55:27 UTC |
There was a problem hiding this comment.
Pull request overview
Adjusts rebroadcast behavior so nodes with zero connected peers don’t get stuck behind a “no capacity” gate, and updates a flaky expectation in the rebroadcaster tests.
Changes:
- Treat an empty network (no channels) as having available capacity in
network::check_capacity(). - Change when
election::broadcast_block()queues blocks for theblock_rebroadcaster. - Relax
block_rebroadcastertest assertion to acceptqueued >= 1instead of exactly1.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
nano/node/network.cpp |
Makes capacity checks succeed when there are no channels. |
nano/node/election.cpp |
Alters when blocks are queued for rebroadcast during election block broadcast. |
nano/core_test/block_rebroadcaster.cpp |
Makes the basic rebroadcaster test tolerant to multiple queued events. |
Comments suppressed due to low confidence (1)
nano/node/network.cpp:346
check_capacity()now returns true when the network has zero channels. This causes the block/vote rebroadcasters to drain their queues and callcheck_and_record()even thoughflood_*will send to 0 peers, meaning the item can enter the rebroadcast cooldown window without ever being transmitted. If a peer connects shortly after, subsequent pushes for the same block/vote can be suppressed for up torebroadcast_cooldown(60s by default), delaying actual propagation. Consider treating an empty network as a special case where the rebroadcaster is allowed to run but does not record a rebroadcast attempt (or only records whensent > 0).
bool nano::network::check_capacity (nano::transport::traffic_type type, size_t target_count) const
{
if (target_count == 0 || size () == 0)
{
return true;
}
auto channels = list (target_count, [type] (auto const & channel) {
return !channel->max (type); // Only use channels that are not full for this traffic type
});
return !channels.empty () && channels.size () >= target_count / 2; // We need to have at least half of the target capacity available
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| duration ().count ()); | ||
| } | ||
|
|
||
| // Random flood for block propagation | ||
| node.block_rebroadcaster.push (status.winner); | ||
| // Random flood for block propagation | ||
| node.block_rebroadcaster.push (status.winner); | ||
| } |
There was a problem hiding this comment.
This change moves node.block_rebroadcaster.push(status.winner) inside the if (!solicitor_a.broadcast(*this)) block. That makes rebroadcaster queuing contingent on confirmation_solicitor actually performing a directed broadcast (and stops it entirely once max_block_broadcasts is reached), which is a behavior change beyond the PR description. Please confirm this gating is intentional, and if so update the PR description (or add a targeted test) to reflect the new propagation behavior.
Treat an empty network as having available capacity so rebroadcasting does not fail early when no channels exist.
Relax the rebroadcaster test to accept multiple queued events instead of assuming the counter stays exactly at one.