Repository navigation
tests: wait for either OUR_HTLC_SUCCESS_TX in test_onchain_middleman_fulfill_after_fail - #9567
Conversation
b8f860a to
5f37da1
Compare
daywalker90
changed the title
Andezion
left a comment
Andezion
left a comment
There was a problem hiding this comment.
Did you consider bitcoind.generate_block(1, wait_for_mempool=1) after waiting for the two broadcasts? l3 can only ever have one of the two txs in the mempool, and nothing else should be there at this point, so maaaaaaybe it would be a little shorter
| # so only one can enter the mempool at a time. Wait for either. | ||
| needle = l3.daemon.logsearch_start | ||
| l3.rpc.releasehtlc(preimage) | ||
| _, txid, _ = l3.wait_for_onchaind_tx('OUR_HTLC_SUCCESS_TX', |
There was a problem hiding this comment.
maybe wait on the type-specific onchaind line instead, such as ['Telling lightningd about OUR_HTLC_SUCCESS_TX to resolve OUR_UNILATERAL/THEIR_HTLC'] * 2. That is the same line wait_for_onchaind_txs uses. Then collect the broadcast txids?
| if m: | ||
| txids.append(bitcoind.rpc.decoderawtransaction(m.group(1))['txid']) | ||
| assert len(txids) >= 2 | ||
| wait_for(lambda: any(t in bitcoind.rpc.getrawmempool() for t in txids[-2:])) |
There was a problem hiding this comment.
wait_for(lambda: any(t in bitcoind.rpc.getrawmempool() for t in txids))? wait_for_logs already ensures there are at least two matches, so the assert never fails, no?
5f37da1 to
1394cb1
Compare
|
Good idea, how about this approach? |
…fulfill_after_fail The two success txs share a wallet UTXO for fee boost, so only one can be in the mempool at a time. Waiting for the first broadcast's txid could latch onto the loser and time out; wait for either instead. Changelog-None
1394cb1 to
26e67fa
Compare
This branch has not been deployed
2 participants
Changelog-None
Fixes: #9549