Repository navigation
tests: wait for the channel_ready retransmission on the node that disconnected - #9645
Merged
daywalker90 merged 1 commit intoOct 26, 2026
Conversation
daywalker90
requested changes
Oct 22, 2026
daywalker90
requested changes
Oct 22, 2026
…connected 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: ElementsProject#9644 Changelog-None
ksedgwic
force-pushed
the
reconnect-no-update-wait-on-disconnecting-node
branch
from
October 23, 2026 17:09
9599676 to
ba18c0d
Compare
Collaborator
Author
|
Both applied: one wait on l2 for "Retransmitting channel_ready" without the daemon name, and the reconnect wait accepts CHANNELD_SHUTTING_DOWN or CLOSINGD_SIGEXCHANGE. The dual-fund job had caught the first one as well: when l1's channel_ready arrives before l2 reaches the depth, dualopend hands over to channeld before the scripted disconnect, so the retransmission on l2 comes from channeld. |
daywalker90
approved these changes
Oct 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
test_reconnect_no_update waited for the first node to retransmit channel_ready after the second node's scripted disconnect, but a node only retransmits if it had sent channel_ready before the disconnect, and when the second node reaches the funding depth first the first node has nothing to retransmit. Wait on the second node, which has always sent it by the time it reconnects. The later wait for a second retransmission after the close was only ever satisfied by that first one, since the fee update after lock-in advances the commitment numbers; it now waits for the reconnect in the closing state instead.
Fixes #9644