Repository navigation
tests: fix races in test_channel_lease_unilat_closes - #9629
daywalker90 wants to merge 1 commit into
Conversation
Andezion
left a comment
There was a problem hiding this comment.
from what i see peer updated blockheight to ... is logged in handle_peer_blockheight_change() (channeld.c at line 902). That runs when l3 receives update_blockheight, which is the RCVD_ADD_HTLC state. At that point the new height is not in any commitment yet? then l3.rpc.close() uses the commitment that lightningd has saved. lightningd saves it only in send_revocation() -> towire_channeld_got_commitsig(), after l3 has received l2 commitment_signed (channeld.c at line 1788 - 1798). l2 sends commitment_signed from the commit timer, after it sends update_blockheight. So this order is still possible:
- l2 sends
update_blockheight - l3 logs
peer updated blockheight to H, and the test continues l2.stop()runs before l2 commit timer fires, or before l3 handlescommitment_signed- l3 closes with the old commitment and old height, and
l3blocks == 4025again
So the window is smaller than before, but it is still there? maybe
l2.daemon.wait_for_log(f'Blockheight: SENT_ADD_ACK_COMMIT->RCVD_ADD_ACK_REVOCATION LOCAL now {height}')
l3.daemon.wait_for_log(f'Blockheight: SENT_ADD_ACK_COMMIT->RCVD_ADD_ACK_REVOCATION LOCAL now {height}')
CI flaked with:
> assert l3blocks == 4032 - 6 - 2 - 1
E assert 4025 == (((4032 - 6) - 2) - 1)
l3's commitment used a blockheight 2 blocks behind the chain, because
l2 was stopped before l3 had saved a commitment with the new height.
A second run flaked with:
E pyln.client.lightning.RpcError: RPC call failed: method: fundchannel
... error: {'code': 301, 'message': 'Could not afford 506268sat using
all 0 available UTXOs: 506696sat short'}
l2 broadcast the l1 funding tx, but did not record its change output
until after the l2->l3 fundchannel with minconf=0 had already failed.
Wait for l3 to log the commitsig carrying the new blockheight before
stopping l2, and wait for l2 to see the funding change before the
minconf=0 fundchannel.
Changelog-None
59cdedb to
3341190
Compare
|
Good catch, i changed it to the |
CI flaked with:
l3's commitment used a blockheight 2 blocks behind the chain, because l2's update_blockheight had not yet been applied when l2 was stopped. A second run flaked with:
l2 broadcast the l1 funding tx, but did not record its change output until after the l2->l3 fundchannel with minconf=0 had already failed.
Wait for l3 to apply the blockheight update before stopping l2, and wait for l2 to see the funding change before the minconf=0 fundchannel.
Changelog-None