Currently the test case may fail intermittently, see #28313
Fix this by changing a number and reducing the failure rate a bit.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | glozow |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
91 | @@ -92,7 +92,7 @@ def test_reorg_relay(self): 92 | # However, the node will answer requests for the tx from the recently-disconnected block. 93 | assert_equal(peer1.last_message["tx"].tx.getwtxid(),tx_disconnected["tx"].getwtxid()) 94 | 95 | - self.nodes[1].setmocktime(int(time.time()) + 30) 96 | + self.nodes[1].setmocktime(int(time.time()) + 300)
Seems like due to poisson announcement timer, with a small probability, the announcement hasn't been scheduled yet. A more sure way to fix this is to revert to system time and just wait for the invs:
# Reset to system time
self.nodes[1].setmocktime(0)
peer1.wait_for_broadcast([tx_before_reorg["tx"].getwtxid(), tx_child["tx"].getwtxid(), tx_disconnected["tx"].getwtxid()])
(And then delete L97-101)
wait_for_broadcast has a (default) timeout of 60 seconds, which I can use here, if you don't like the 300.
Other than that, I think it is fine to use mocktime here.
Oh true. I suppose in the very rare scenario that it's a really long time, fastforward + immediately fail is better than waiting 60 seconds and failing. Would prefer 60 over 300 but nbd.
Concept ACK, thanks Marco
ACK fa5cc3ccfb15d05775ace9c1827b06203ce17116
Milestone
26.0