Merge #11538: qa: Fix race condition failures in replace-by-fee.py, sendheaders.py
commit57ee73990f1ce29916adfd99f93eae1ccea1a43b
authorMarcoFalke <falke.marco@gmail.com>
Mon, 23 Oct 2017 15:19:02 +0000 (23 17:19 +0200)
committerMarcoFalke <falke.marco@gmail.com>
Mon, 23 Oct 2017 15:19:26 +0000 (23 17:19 +0200)
treec1a796e914022c0e04f8b0341ff68a2ed630aea3
parent6157e8ce3937af3f46d3e7dd922d19d6dc272145
parent6d51eaefe924bfaf2b0f4928dd6020023733480f
Merge #11538: qa: Fix race condition failures in replace-by-fee.py, sendheaders.py

6d51eaefe qa: Fix race condition in sendheaders.py (Suhas Daftuar)
c96b2e4f0 qa: Fix replace-by-fee race condition failures (Suhas Daftuar)

Pull request description:

  I think #11407 broke replace-by-fee by introducing a race condition.  I was observing frequent failures of replace-by-fee locally, always with a mempool sync failure (the sync call was added in #11407).

  It appeared to me like there were two causes: sometimes the node would be in IBD and not request the transaction that was relayed; other times the blocks generated in make_utxo wouldn't have relayed quickly enough for the spend of the transaction to be accepted.  I believe I've fixed both potential errors.

  ping @instagibbs

  Edit: I found a race condition in the sendheaders.py test, where if the verack from the python node wasn't processed before the first block in the test was generated, then no block announcement would go out to that peer, breaking the test.  Fixed by adding a sync_with_ping after waiting for verack.

Tree-SHA512: 6ad160966e432c151c1ce6e88ae67e60e47123523bda3755cf7697a00e1a5ba38de8561751826e3d7cf0e492f8c2aec298e1b4de8424ebbaf497f099a1ef1d07