test: Document rare failure in test_inv_block better #35324

This test may fail intermittently, see the tracking issue #19732 and https://github.com/bitcoin-core/gui/actions/runs/25819423445/job/75856716144?pr=936#step:10:5303 specifically:

2026-05-13T19:37:19.624321Z TestFramework (INFO): Tx should be received at node 1 after 64 seconds
2026-05-13T20:17:19.627627Z TestFramework (ERROR): Unexpected exception:
Traceback (most recent call last):
  File "/home/runner/work/_temp/test/functional/test_framework/test_framework.py", line 143, in main
    self.run_test()
  File "/home/runner/work/_temp/build/test/functional/p2p_tx_download.py", line 413, in run_test
    test()
  File "/home/runner/work/_temp/build/test/functional/p2p_tx_download.py", line 130, in test_inv_block
    self.sync_mempools()
  File "/home/runner/work/_temp/test/functional/test_framework/test_framework.py", line 721, in sync_mempools
    raise AssertionError("Mempool sync timed out after {}s:{}".format(
AssertionError: Mempool sync timed out after 2400s:
  {'2db3a22f9370eb32f110597882acebef1c76cf319837bac69b829917730d2349'}
  set()

The test assumes that node1 gets the tx from its honest outbound peer (node0). However, the same connection is inbound from the view of node0, so node0 will use an exponentially distributed delay, which may be more than the expected timeout.

Document this clearer, so that the this specific failure can simply be re-run without having to spend a long time thinking and debugging it every time it happens.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35324.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

The failure is too rare to reproduce reliably, but if someone want to reproduce it on master (or this pull request), to see the failure locally for themselves, they can use something like:

diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 631e968da7..c036fa14ca 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -164,3 +164,3 @@ static constexpr auto ROTATE_ADDR_RELAY_DEST_INTERVAL{24h};
  *  Blocks and peers with NetPermissionFlags::NoBan permission bypass this. */
-static constexpr auto INBOUND_INVENTORY_BROADCAST_INTERVAL{5s};
+static constexpr auto INBOUND_INVENTORY_BROADCAST_INTERVAL{50s};
 /** Average delay between trickled inventory transmissions for outbound peers.

and then run the test a bunch of times, until it fails.

ACK fa890988889b4b2ee167369834a42bf391d4fb1c

Seems fine to add the comment, and force a SendMessages pass, even though this doesn't affect the "flakiness" from the poisson delay.

even though this doesn't affect the "flakiness"

Correct. Maybe a more complete fix would be to return False + Retry automatically until it passes. Though, the failure should be so rare that I am not sure if this is worth the additional code+review?

the failure should be so rare that I am not sure if this is worth the additional code+review

i agree it's not worth covering