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

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

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

Recreated from #9404 (original head fork went private; identical commits, no content changes). Originally opened 2026-08-12.

♻️ 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

vincenzopalazzo · 2026-08-17T11:14:26Z

Hi @daywalker90 👋 — this replaces #9404 (auto-closed when my fork went private; identical commits). Fixes the disconnect-on-unknown-channel_reestablish reconnect loop hitting dual-fund peers. Targeting v26.09 — would appreciate a review before the RC cut, happy to address feedback.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

…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 ElementsProject#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#8822 Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Sets up ElementsProject#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>

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Andezion · 2026-08-18T15:44:04Z

+/* How many channel_reestablish for channels we don't know we answer without
+ * hanging up. An honest peer needs one per stale channel; past that it's
+ * cheaper for us to make them reconnect (which connectd rate-limits). */
+#define MAX_UNKNOWN_CHANNEL_REESTABLISHES 10


daywalker90 · 2026-08-19T11:12:21Z

____________________________ test_disconnect_opener ____________________________
[gw4] linux -- Python 3.10.20 /home/runner/work/lightning/lightning/.venv/bin/python
node_factory = <pyln.testing.utils.NodeFactory object at 0x7f4d3abdca90>
@pytest.mark.openchannel('v1')
@pytest.mark.openchannel('v2')
# FIXME: https://github.com/ElementsProject/lightning/issues/8822
@pytest.mark.flaky(reruns=1)
def test_disconnect_opener(node_factory):
# Now error on opener side during channel open.
disconnects = ['-WIRE_OPEN_CHANNEL',
'+WIRE_OPEN_CHANNEL',
'-WIRE_FUNDING_CREATED']
if EXPERIMENTAL_DUAL_FUND:
disconnects = ['-WIRE_OPEN_CHANNEL2',
'+WIRE_OPEN_CHANNEL2',
'-WIRE_TX_ADD_INPUT',
'+WIRE_TX_ADD_INPUT',
'-WIRE_TX_ADD_OUTPUT',
'+WIRE_TX_ADD_OUTPUT',
'-WIRE_TX_COMPLETE',
'=WIRE_TX_COMPLETE']
l1 = node_factory.get_node(disconnect=disconnects,
may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l2 = node_factory.get_node(may_reconnect=EXPERIMENTAL_DUAL_FUND,
options={'dev-no-reconnect': None})
l1.fundwallet(2000000)
for d in disconnects:
l1.rpc.connect(l2.info['id'], 'localhost', l2.port)
> with pytest.raises(RpcError):
E Failed: DID NOT RAISE <class 'pyln.client.lightning.RpcError'>
tests/test_connection.py:507: Failed

This is a test related to this PR if i'm not mistaken and it failed in CI: https://github.com/ElementsProject/lightning/actions/runs/32025646089/job/96039521307?pr=9427

vincenzopalazzo added this to the v26.09 milestone Aug 17, 2026

vincenzopalazzo mentioned this pull request Aug 17, 2026
lightningd: don't disconnect when sending error for unknown channel_reestablish #9404
Closed
2 tasks

vincenzopalazzo mentioned this pull request Aug 17, 2026
lightningd: don't force-close when fulfilled HTLC removal is in progress #9431
Open

vincenzopalazzo added a commit to vincenzopalazzo/lightning that referenced this pull request Aug 17, 2026
changelog: add Fixed entry forElementsProject#9427
623c770
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo added 3 commits August 17, 2026 13:35

changelog: add Fixed entry forElementsProject#9427
92767d6
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

vincenzopalazzo force-pushed the fix/dual-funding-reconnect-loop branch from 623c770 to 92767d6Compare August 17, 2026 11:35

Andezion approved these changes Aug 18, 2026
View reviewed changes

clemenslosbichler-cloud mentioned this pull request Aug 20, 2026
lightningd: don't disconnect when sending error for unknown channel_reestablish clemenslosbichler-cloud/lightning#2
Open