-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Add functional test test_txid_inv_delay #20171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
sipa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK
Linter error: test/functional/p2p_segwit.py:14:1: F401 'test_framework.messages.msg_verack' imported but unused
637d7a1 to
f0fe840
Compare
|
Thanks, updated at f0fe840. See if this comment needs further modification. |
test/functional/p2p_tx_download.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait until right above wouldn't allow this line to happen if tx_getdata_count == 0. So we're checking it's NOT more than 1? Is it a worthy check?... It has nothing to do with delays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeh, testnode wait_until grabs p2p_lock so this is redundant with L233
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, in fact it sounds other new functional tests added with #19988 have a redundant p2p lock tacking so added a new commit to remove this oversight. Unless @MarcoFalke they serve something else ?
test/functional/p2p_tx_download.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps also worth testing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a test mutation.
test/functional/p2p_tx_download.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't NONPREF_PEER_TX_DELAY also be applied here?
Anyway, I'd first jump in NONPREF_PEER_TX_DELAY to see that it's not enough time passed, and then jump TXID_RELAY_DELAY again to see that enough time passed? I think that's what is supposed to happen..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The positive case was already tested in test_preferred_inv but added a mutation to cover the negative one, i.e applying NONPREF_PEER_TX_DELAY on non-preferred peers.
|
Concept ACK |
glozow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK
test/functional/p2p_tx_download.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeh, testnode wait_until grabs p2p_lock so this is redundant with L233
test/functional/p2p_tx_download.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this supposed to test that the node waits for the duration of TXID_RELAY_DELAY? Seems like it just confirms that the node doesn't send a getdata immediately, then sends it ~TXID_RELAY_DELAY later? I had imagined making TestP2PConn record the time at which it receives getdatas, then asserting that the time difference from sending the inv is at least TXID_RELAY_DELAY... don't think it could use setmocktime though so idk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you can achieve this with current p2p framework, we can write to the mocktime but can we read it from it ? A quick look, I don't find test doing it so not sure that's a feature of our current test framework. Note that was already the way done by legacy (pre-#19988) tx-download tests. But lmk if there is way to do so I don't see
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't find test doing it so not sure that's a feature of our current test framework
Yeah, I haven't seen an example either. The way I'd do it is just use sleep() instead of setmocktime... 2 seconds isn't too bad when the tests are running in parallel, but fosho not ideal.
|
ACK f0fe840ace0d317dcde48d1f21554f884accbbf9 |
f0fe840 to
c55ce67
Compare
|
Thanks @naumenkogs, @glozow for reviews, updated addressing your comments at c55ce67 |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, 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. |
jonatack
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach ACK. Verified the new test does fail per the PR description.
Its usage is extended beyond p2p_segwit.py in next commit.
Add a simple functional test to cover TXID_RELAY_DELAY as applied as a TxRequestTracker parameter in AddTxAnnoucement.
Add a booelan arg to test_preferred_inv to cover NONPREF_PEER_TX_DELAY as applied as a TxRequestTracker parameter in AddTxAnnouncement.
New functional test coverage of tx download was added by bitcoin#19988, but `with p2p_lock` is redundant for some tests with `wait_until` test helper, already guaranteeing test lock tacking.
c55ce67 to
bc4a230
Compare
|
@naumenkogs @jonatack @glozow @MarcoFalke if you have few minutes to review again this PR, it hasn't changed and I think all previous considerations have been addressed. |
|
ACK bc4a230 |
bc4a230 Remove redundant p2p lock tacking for tx download functional tests (Antoine Riard) d3b5eac Add mutation for functional test test_preferred_inv (Antoine Riard) 06efb31 Add functional test test_txid_inv_delay (Antoine Riard) a07910a test: Makes wtxidrelay support a generic P2PInterface option (Antoine Riard) Pull request description: This is a simple functional test to increase coverage of bitcoin#19988, checking that txid announcements from txid-relay peers are delayed by TXID_RELAY_DELAY, assuming we have at least another wtxid-relay peer. You can verify new test with the following diff : ``` diff --git a/src/net_processing.cpp b/src/net_processing.cpp index f14db37..2a2805df5 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -773,7 +773,7 @@ void PeerManager::AddTxAnnouncement(const CNode& node, const GenTxid& gtxid, std auto delay = std::chrono::microseconds{0}; const bool preferred = state->fPreferredDownload; if (!preferred) delay += NONPREF_PEER_TX_DELAY; - if (!gtxid.IsWtxid() && g_wtxid_relay_peers > 0) delay += TXID_RELAY_DELAY; + //if (!gtxid.IsWtxid() && g_wtxid_relay_peers > 0) delay += TXID_RELAY_DELAY; const bool overloaded = !node.HasPermission(PF_RELAY) && m_txrequest.CountInFlight(nodeid) >= MAX_PEER_TX_REQUEST_IN_FLIGHT; if (overloaded) delay += OVERLOADED_PEER_TX_DELAY; ``` ACKs for top commit: laanwj: ACK bc4a230 Tree-SHA512: 150e806bc5289feda94738756ab375c7fdd23c80c12bd417d3112043e26a91a717dc325a01079ebd02a88b90975ead5bd397ec86eb745c7870ebec379a8aa711
This is a simple functional test to increase coverage of #19988, checking that txid announcements from txid-relay peers are delayed by TXID_RELAY_DELAY, assuming we have at least another wtxid-relay peer.
You can verify new test with the following diff :