Add coverage for the case where a peer is protected when it pretends to have a block.
Also, add some ASSERT_DEBUG_LOG to document the tests for the reader.
Add coverage for the case where a peer is protected when it pretends to have a block.
Also, add some ASSERT_DEBUG_LOG to document the tests for the reader.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For detailed information about the code coverage, see the test coverage report.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Concept ACK, will review soon
Concept ACK
Are you still working on this?
Closing this as it has not had any activity in a while. If you are interested in continuing work on this, please leave a comment so that it can be reopened.
Ok, I'll rebase
217 | BOOST_CHECK(vNodes.back()->fDisconnect == false); 218 | 219 | + vNodes[max_outbound_full_relay - 1]->fDisconnect = false; 220 | + peerLogic->UpdateLastBlockAnnounceTime(vNodes.back()->GetId(), 0); 221 | + 222 | + // Set CanDirectFetch() to true by generating a block
Why is this necessary, do we care if CanDirectFetch is true? The tests passes without this block (if we set nVersion on dummy below).
225 | + block->nTime = count_seconds(time_later); 226 | + SolvePow(*block); 227 | + m_node.chainman->ProcessNewBlock(block, true, true, nullptr); 228 | + } 229 | + // Last node pretends to send a block 230 | + std::vector<CBlock> headers;
could be moved inside the following block
Concept ACK.
I wonder if it's possible (and worth it) to tweak the test such that it would have caught #26172.
Sending the block via p2p like this test does also updates m_last_block_announcement, however I think we'd need to add a getter to check this directly.
Or maybe it could work to have 5 nodes send new block headers via p2p instead of 1, such that only MAX_OUTBOUND_PEERS_TO_PROTECT_FROM_DISCONNECT=4 of them get protected, and the fifth also gets saved from disconnect via m_last_block_announcement.
Ping @MarcoFalke, apparently :)
I wonder if it's possible (and worth it) to tweak the test such that it would have caught #26172.
I have a test for that but haven't made the PR yet (I'll do that this week). I'll compare what I have to this PR since there's likely some overlap. @LarryRuane any update on the test?