A similar failure has just happened in p2p_compactblocks.py.

Why do the timeout failures give the impression that increasing the timeout will fix them?

Why do the timeout failures give the impression that increasing the timeout will fix them?

No, I don't think that this PR fixes timeout failures. It mitigates them by tuning of a parameter which is used already.

Btw, the default value in CI:

Increasing the timeout this far should only be needed when running on slow environments (such as valgrind on a raspberry pi).

The underlying issue here is a missing sync_all. There is a patch fixing this available for more than a year (#23300), but review interest seems low.

To explain:

test_feefilter generates blocks and txs on node1 (without syncing with node0). Then node1 won't accept/request the txs (because it is still busy syncing the blocks). Thus the test fails (times out).

https://cirrus-ci.com/task/6483187195969536?logs=functional_tests#L1202

 node0 2021-11-07T19:20:39.512760Z [C:\Users\ContainerAdministrator\AppData\Local\Temp\cirrus-ci-build\src\net_processing.cpp:3405]
[ProcessMessage] f131ea1bb61a094f7d4a4d16298c321212a7c8dd40a6645db59b3e25e623dc75 from peer=0 was not accepted: bad-txns-premature-spend-of-coinbase, tried to spend coinbase at depth 64 

Just checked, #20362 was opened on Nov 10th, so it is a year short 2 days, not more than a year, but still.

So yeah.

NACK on this pull unless there is a reason to do this.

Closing in favor of #23300.