lightningd: don't disconnect when sending error for unknown channel_reestablish by vincenzopalazzo · Pull Request #9404 · ElementsProject/lightning

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo · 2026-08-12T09:14:59Z

♻️ Re-creation of #8988, which was auto-closed on 2026-08-11 when my fork was detached from the repository network (GitHub cannot reopen PRs closed by a detachment). Branch content is unchanged (head 592381a58); the previous review discussion remains on #8988.

Note: the outstanding review feedback from @nGoline on #8988 (cite BOLT #1error semantics in the PR) still applies and is being addressed.

Summary

When receiving WIRE_CHANNEL_REESTABLISH for an unknown channel, send the error without disconnecting
Prevents a race where the disconnect arrives before the error, leaving the peer with a stale saved channel in DUALOPEND_OPEN_COMMIT_READY that retries indefinitely

The 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 sends CHANNEL_REESTABLISH, the other side sends error + disconnect. The disconnect races with the error delivery -- if the peer's dualopend doesn't receive the error before the socket closes, dualopen_errmsg is called with disconnect=false, which calls channel_fail_transient instead of deleting the channel, and the cycle repeats.

By not disconnecting, the error reliably reaches the peer's dualopend, which processes it via peer_failed_received_errmsg(disconnect=true) and properly deletes the stale channel.

Test plan

Verify make check-units passes (done locally)
CI integration tests, particularly test_disconnect_opener

Fixes#8822

…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 sent an error and hung up. Our error does make it onto the wire: disconnect_peer() -> drain_peer() in connectd/multiplex.c gives peer_outq 5 seconds to flush first. The race is on the receiving node: its connectd hands the error to dualopend and tears the subds down on EOF at the same time, and when dualopend loses that race lightningd only sees "Owning subdaemon dualopend died" (subd.c passes peer_fd=NULL, disconnect=false), so dualopen_errmsg() keeps the DUALOPEND_OPEN_COMMIT_READY channel for a later reconnect. It then reestablishes on every reconnect, and we error and hang up again. BOLT #1 only requires that a node sending `error` fails the channel(s) the error refers to; it never says to drop the connection, and here we don't know the channel, so there is nothing for us to fail. So send the error and stay connected: the peer's dualopend then reliably reads it and forgets the channel. Since we no longer hang up, bound how many unknown-channel reestablishes we answer on a single connection, so a peer can't use this to make us log and write errors indefinitely. Changelog-Fixed: dual-funding reconnect loop when peer doesn't know about a saved channel Fixes: ElementsProject/lightning#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up #8822: l1 drops the last tx_complete after dualopend has decided the commitment is ready, so l1 saves a DUALOPEND_OPEN_COMMIT_READY channel that l2 never saved. On reconnect l1 reestablishes a channel l2 doesn't know, and l2 has to answer with an error and stay connected. Note this pins the new behaviour rather than the loop itself: the loop is a race on l1's side (see the previous commit), and locally l1 wins it and forgets the channel even without the fix, so a strict xfail reproduction would just be flaky. The test does fail without the fix, on l2 hanging up. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo · 2026-08-17T11:01:28Z

Superseded by #9427 — recreated from the public fork because this PR's head repo is now private and GitHub cannot reopen it.

vincenzopalazzo added 2 commits August 8, 2026 14:49

vincenzopalazzo closed this Aug 12, 2026