lightningd: don't disconnect when sending error for unknown channel_reestablish#8988
Open
vincenzopalazzo wants to merge 2 commits intoElementsProject:masterfrom
Open
Conversation
…eestablish When a peer sends WIRE_CHANNEL_REESTABLISH for a channel we don't know about (e.g. dual-funding where we deleted the unsaved channel on disconnect but the peer saved it in DUALOPEND_OPEN_COMMIT_READY), we send an error and disconnect. The disconnect races with the error delivery: the peer's dualopend may not receive the error before the connection drops, so the channel survives as a transient failure and the peer retries on every reconnect, creating an infinite loop. Fix this by sending the error without disconnecting for the WIRE_CHANNEL_REESTABLISH case, so the peer's dualopend reliably receives the error and cleans up the stale channel. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
madelinevibes
added
the
Status::Ready for Review
Since we no longer disconnect when receiving a channel_reestablish for an unknown channel, the test needs to explicitly disconnect and reconnect after restorefrompeer() so the stub channel triggers the bogus channel_reestablish flow in peer_connected_hook_final. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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
2 participants
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.
Summary
WIRE_CHANNEL_REESTABLISHfor an unknown channel, send the error without disconnectingDUALOPEND_OPEN_COMMIT_READYthat retries indefinitelyThe bug: during dual-funding, if one side saves the channel (reaches
DUALOPEND_OPEN_COMMIT_READY) but the other deletes its unsaved copy on disconnect, reconnects create an infinite loop. The saved side sendsCHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer'sdualopenddoesn't receive the error before the socket closes,dualopen_errmsgis called withdisconnect=false, which callschannel_fail_transientinstead of deleting the channel, and the cycle repeats.By not disconnecting, the error reliably reaches the peer's
dualopend, which processes it viapeer_failed_received_errmsg(disconnect=true)and properly deletes the stale channel.Test plan
make check-unitspasses (done locally)test_disconnect_openerFixes #8822