Inspired by refactorings in #30000 as the coverage appeared a bit sparse.
Added some minimal border value testing, timeouts, and tightened existing assertions.
Inspired by refactorings in #30000 as the coverage appeared a bit sparse.
Added some minimal border value testing, timeouts, and tightened existing assertions.
<!--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.
175 | {
176 | - size_t sizeBefore = orphanage.CountOrphans();
177 | orphanage.EraseForPeer(i);
178 | - BOOST_CHECK(orphanage.CountOrphans() < sizeBefore);
179 | + BOOST_CHECK(orphanage.CountOrphans() == expected_num_orphans - 2);
180 | + expected_num_orphans -= 2;
nit: just update the value beforehand?
expected_num_orphans -= 2;
BOOST_CHECK(orphanage.CountOrphans() == expected_num_orphans);
done
203 | + tx.vin[0].prevout.n = 0; 204 | + tx.vin[0].prevout.hash = Txid::FromUint256(InsecureRand256()); 205 | + tx.vin[0].scriptSig << OP_1; 206 | + tx.vout.resize(1); 207 | + tx.vout[0].nValue = 1*CENT; 208 | + tx.vout[0].scriptPubKey = GetScriptForDestination(PKHash(key.GetPubKey()));
Is there a reason to do this manually instead of using MakeTransactionSpending()?
nope, changed
213 | + 214 | + // Jump ORPHAN_TX_EXPIRE_TIME minutes, orphan should be timed out on limiting 215 | + SetMockTime(GetTime() + 20 * 60); 216 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 1); 217 | + orphanage.LimitOrphans(1, rng); 218 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 0);
Maybe out of scope but I wonder if it would be best to add a current_time parameter to the TxOrphanage methods to make it easier to test and fuzz the expiration (also should have a test for the sorting for GetChildrenFromSamePeer results)
probably a good idea, though you might have better opinions on orphanage interface. I tightened the time testing a bit more by setting mocktime at beginning, then checking boundary conditions via subsequent setting of the time.
210 | + // One second shy of expiration 211 | + SetMockTime(now - 1 + 20 * 60); 212 | + orphanage.LimitOrphans(1, rng); 213 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 1); 214 | + 215 | + // Jump ORPHAN_TX_EXPIRE_TIME minutes, orphan should be timed out on limiting
Note you've only jumped 1 second here
done
206 | + orphanage.AddTx(timeout_tx, 0); 207 | + orphanage.LimitOrphans(1, rng); 208 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 1); 209 | + 210 | + // One second shy of expiration 211 | + SetMockTime(now - 1 + 20 * 60);
Would be nice if the constants were moved to txorphanage.h so we don't need the magic number here. Could be useful in other tests as well.
done in first commit now
lgtm
rebased due to silent merge conflict, with cleanups suggested by @glozow :+1:
181 | + 182 | + // Non-existent peer; nothing should be deleted 183 | + orphanage.EraseForPeer(/*peer=*/-1); 184 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), expected_num_orphans); 185 | + 186 | + // Test EraseOrphansFor: Each of first three peers announced
EraseOrphansFor doesn't exist
:sweat: fixed
almost ack 6831f3972ee5d660ce0bff9bb573745338417544, thanks for taking suggestions
ACK eaf4de028de8fa13227b6089785889f1c6c15b4d
182 | + // Non-existent peer; nothing should be deleted 183 | + orphanage.EraseForPeer(/*peer=*/-1); 184 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), expected_num_orphans); 185 | + 186 | + // Each of first three peers announced 187 | + // two transactions each.
Took me a while to understand why only the first 3 peers announced 2 txs each, but it's infact the first 10 peers as per the above 3 loops that announced 2 txs each - the third tx for each of them being ignored because of its large size.
I'm switching the word to "stored" to be clearer
201 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), expected_num_orphans); 202 | + orphanage.LimitOrphans(/*max_orphans=*/expected_num_orphans - 1, rng); 203 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), expected_num_orphans - 1); 204 | orphanage.LimitOrphans(40, rng); 205 | - BOOST_CHECK(orphanage.CountOrphans() <= 40); 206 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 40);
Nit: Tying it to expected_num_orphans like expected_num_orphans -3 in the LimitOrphans call would make it more explicit (but not necessarily in the BOOST_CHECK), otherwise it made me wonder whether the current count is more than 40 or not.
good point, I added an assert to make it clear its larger, since I think that's the assertion we really want
209 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 10); 210 | orphanage.LimitOrphans(0, rng); 211 | - BOOST_CHECK(orphanage.CountOrphans() == 0); 212 | + BOOST_CHECK_EQUAL(orphanage.CountOrphans(), 0); 213 | + 214 | + // Add one more orphan, check timeout logic
Can you please share how exactly is this being done check timeout logic here?
I see from the AddTx code that if the tx size is more than the standard weight, then it will not be added in the orphanage. Is the timeout logic here that the size of this tx is less than the standard weight and therefore it's inserted?
orphans are expired in the first part of LimitOrphans
considering this resolved
13 | @@ -14,6 +14,11 @@ 14 | #include <map> 15 | #include <set> 16 | 17 | +/** Expiration time for orphan transactions */ 18 | +static constexpr auto ORPHAN_TX_EXPIRE_TIME{20min}; 19 | +/** Minimum time between orphan transactions expire time checks */ 20 | +static constexpr auto ORPHAN_TX_EXPIRE_INTERVAL{5min}; 21 | +
+1 on moving these to the header file!
reACK 172c1ad
Thanks for very quickly addressing my comments @instagibbs, appreciate it!
reACK 172c1ad026cc38c6f52679e74c14579ecc77c48e
@achow101 RFM?
ACK 172c1ad026cc38c6f52679e74c14579ecc77c48e