tests: wait for the channel_ready retransmission on the node that disconnected

test_reconnect_no_update waited for l1 to log "Retransmitting
channel_ready" after l2's scripted disconnect on sending channel_ready.
channeld, and dualopend in the dual-funding variant, retransmit only
when the node had sent channel_ready before the disconnect, which
lightningd derives from the channel's scid being known. When l2
reaches the funding depth and disconnects before l1 has seen the
block, l1 sends its channel_ready for the first time after the
reconnect, nothing is retransmitted on l1, and the wait times out.

Wait on l2 instead: it has sent channel_ready by the time it
reconnects, whichever node saw the block first. With dual funding
the retransmission comes from l2's dualopend, or from channeld when
l1's channel_ready arrived before l2 reached the depth and dualopend
had already handed the channel over, so the wait does not name the
daemon.

The second wait on l2, after the close, was only ever satisfied by
that same first retransmission: the fee update after lock-in advances
the commitment numbers, after which channel_ready is not retransmitted.
Wait for the reconnect in the closing state instead, which is what
that part of the test covers. l2 is in CHANNELD_SHUTTING_DOWN or
already in CLOSINGD_SIGEXCHANGE then, depending on whether its
channeld reported both shutdowns before the disconnect took it down,
so accept either.

Fixes: #9644
Changelog-None

Author: ksedgwic

tests/test_connection.py

@@ -763,22 +763,32 @@ def test_reconnect_no_update(node_factory, executor, bitcoind):
     # LightningNode.fundchannel will fund the channel and generate a
     # block. The block triggers the channel_ready message, which
     # causes a disconnect. The retransmission is then caused by the
-    # automatic retry.
+    # automatic retry.  Wait for it on l2: l2 disconnects as it sends
+    # channel_ready, so it has sent it by the time it reconnects, while
+    # l1 may not have reached the funding depth yet and would then send
+    # its channel_ready for the first time instead of retransmitting.
+    # With dual funding the retransmission comes from l2's dualopend, or
+    # from channeld when l1's channel_ready arrived before l2 reached
+    # the depth and the channel had already moved on, so match either.
     fundchannel_exec = executor.submit(l1.fundchannel, l2, 10**6, False)
-    if l1.config('experimental-dual-fund'):
-        l1.daemon.wait_for_log(r"dualopend.* Retransmitting channel_ready for channel")
-    else:
-        l1.daemon.wait_for_log(r"channeld.* Retransmitting channel_ready for channel")
+    l2.daemon.wait_for_log(r"Retransmitting channel_ready for channel")
     sync_blockheight(bitcoind, [l1, l2])
     fundchannel_exec.result()
     l1.stop()
 
     # For closingd reconnection
     l1.daemon.start()
     # Close will trigger the -WIRE_SHUTDOWN and we then wait for the
-    # automatic reconnection to trigger the retransmission.
+    # automatic reconnection to complete the close.  channel_ready is
+    # not retransmitted on this reconnect: it is only retransmitted
+    # while both commitment numbers are still 1, and the fee update
+    # after lock-in has already advanced them.  The earlier wait for
+    # it on l2 was satisfied by the first reconnect's retransmission.
+    # l2 is in CHANNELD_SHUTTING_DOWN or already in CLOSINGD_SIGEXCHANGE
+    # at the reconnect, depending on whether its channeld reported both
+    # shutdowns before the disconnect took it down.
     l1.rpc.close(l2.info['id'], 0)
-    l2.daemon.wait_for_log(r"channeld.* Retransmitting channel_ready for channel")
+    l2.daemon.wait_for_log(r"Peer has reconnected, state (CHANNELD_SHUTTING_DOWN|CLOSINGD_SIGEXCHANGE)")
     l1.daemon.wait_for_log(r"CLOSINGD_COMPLETE")