Stop enqueueing messages for disconnected peers by TheBlueMatt · Pull Request #4094 · lightningdevkit/rust-lightning

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt · 2025-09-19T12:33:38Z

If a channel operation occurs while a peer is disconnected, we'll
still have a PeerState for that peer. Historically, we haven't
bothered to check if a peer is actually connected before we push
new messages onto the PeerState::pending_msg_events field,
leaving us sending messages into the void.

This is generally not an issue as
ChannelManager::get_and_clear_pending_msg_events should be called
very regularly, removing these messages and then dropping them as
PeerManager won't have anything to do with them.

Still, there is a race condition here - if a peer manages to
connect between the generation of one such message and when
get_and_clear_pending_msg_events is called, we may enqueue a
message to the peer which makes no sense and could lead to a
spurious channel closure (especially in the case of an async
ChannelMonitorUpdate completion or async signing operation, which
often lead to normal channel message generation).

Further, if a peer is slow to send their channel_reestablish
message after connection this race could be substantially more
likely, as such normal channel messages may be nonsense until we've
completed the reestablish dance (i.e. the later reestablish dance
may lead us to re-send the same messages again immediately).

Here we remove most of the cases where we enqueue messages for
disconnected peers.

Note that we differentiate between two different checks for
connected-ness - for cases where we're sending an error or gossip
messages, we allow the messages to be enqueued if the peer is
connected at all. For most other cases, we only allow messages to
be enqueued if the peer is connected and the channel has
completed its reestablish dance (if required, i.e. the channel is
"connected").

Fixes#4036

If a channel operation occurs while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push new messages onto the `PeerState::pending_msg_events` field, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Still, there is a race condition here - if a peer manages to connect between the generation of one such message and when `get_and_clear_pending_msg_events` is called, we may enqueue a message to the peer which makes no sense and could lead to a spurious channel closure (especially in the case of an async `ChannelMonitorUpdate` completion or async signing operation, which often lead to normal channel message generation). Further, if a peer is slow to send their `channel_reestablish` message after connection this race could be substantially more likely, as such normal channel messages may be nonsense until we've completed the reestablish dance (i.e. the later reestablish dance may lead us to re-send the same messages again immediately). Here we remove most of the cases where we enqueue messages for disconnected peers. Note that we differentiate between two different checks for connected-ness - for cases where we're sending an `error` or gossip messages, we allow the messages to be enqueued if the peer is connected at all. For most other cases, we only allow messages to be enqueued if the peer is connected *and* the channel has completed its reestablish dance (if required, i.e. the channel is "connected").

If a channel is failed while a peer is disconnected, we'll still have a `PeerState` for that peer. Historically, we haven't bothered to check if a peer is actually connected before we push the `error` message onto the `PeerState::pending_msg_events` queue, leaving us sending messages into the void. This is generally not an issue as `ChannelManager::get_and_clear_pending_msg_events` should be called very regularly, removing these messages and then dropping them as `PeerManager` won't have anything to do with them. Further, when the the message is an `error`, if a peer happens to connect between when we push the message and when `get_and_clear_pending_msg_events` is called the worst that happens is they get the `error` message we'd end up sending them when they try to reestablish the channel anyway. Still, its awkward to leave the `error`s lying around in a message queue for a disconnected peer, so we remove them here.

In the previous two commits we stopped enqueueing messages for disconnected peers. Here we add some basic test coverage of these changes by asserting that there are no queued messages for a peer when they (re-)connect. We also add a few assertions that a peer is connected when we push a message onto the queu, in cases where we expect a peer to be connected.

ldk-reviews-bot · 2025-09-19T12:33:41Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

codecov · 2025-09-19T12:50:45Z

Codecov Report

❌ Patch coverage is 82.53012% with 29 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.60%. Comparing base (50391d3) to head (47a3e5c).
⚠️ Report is 25 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	79.57%	22 Missing and 7 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4094 +/- ##
==========================================
- Coverage 88.61% 88.60% -0.01% 
==========================================
Files 176 176 Lines 132099 132161 +62 Branches 132099 132161 +62 ==========================================
+ Hits 117060 117103 +43 - Misses 12365 12386 +21 + Partials 2674 2672 -2

Flag	Coverage Δ
fuzzing	`21.56% <13.19%> (-0.38%)`	⬇️
tests	`88.44% <82.53%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-09-22T00:00:29Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Simple enough, going to land this.

It seems that going forward the peer connectedness could be better reflected by the types?

ldk-reviews-bot · 2025-09-22T11:55:32Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2025-09-22T12:27:03Z

Yea we could hide the message queue behind some enum and accessor, but I'm not sure that's a huge deal - we just wipe the queue on connect and only send a message or two per channel max in the worst case. Whats actually a problem is sending a message for a channel when that channel is waiting on a channel_reestablish but the peer is connected. That's somewhat more difficult to fix in channelmanager.rs without yet more state from channel leaking up (which this PR kinda does too, sadly).

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

TheBlueMatt added 3 commits September 19, 2025 12:16

TheBlueMatt added this to the 0.2 milestone Sep 19, 2025

tnull self-requested a review September 19, 2025 12:40

tnull approved these changes Sep 22, 2025
View reviewed changes

tnull merged commit 341e8e4 into lightningdevkit:mainSep 22, 2025
25 checks passed

TheBlueMatt mentioned this pull request Sep 22, 2025
Clean up persistence constants #4105
Closed

Uh oh!

Conversation

TheBlueMatt commented Sep 19, 2025

Uh oh!

ldk-reviews-bot commented Sep 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecovBot commented Sep 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Sep 22, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Sep 22, 2025

Uh oh!

Uh oh!

TheBlueMatt commented Sep 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Sep 19, 2025

Uh oh!

ldk-reviews-bot commented Sep 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecovBot commented Sep 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Sep 22, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Sep 22, 2025

Uh oh!

Uh oh!

TheBlueMatt commented Sep 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Sep 19, 2025

Uh oh!

ldk-reviews-bot commented Sep 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecovBot commented Sep 19, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Sep 22, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Sep 22, 2025

Uh oh!

Uh oh!

TheBlueMatt commented Sep 22, 2025

Uh oh!

Reviewers

ldk-reviews-bot commented Sep 19, 2025•
edited
Loading

codecovBot commented Sep 19, 2025•
edited
Loading

ldk-reviews-bot commented Sep 19, 2025•
edited
Loading

codecovBot commented Sep 19, 2025•
edited
Loading

ldk-reviews-bot commented Sep 19, 2025•
edited
Loading

codecovBot commented Sep 19, 2025•
edited
Loading

ldk-reviews-bot commented Sep 19, 2025•
edited
Loading

codecovBot commented Sep 19, 2025•
edited
Loading

ldk-reviews-bot commented Sep 19, 2025•
edited
Loading

codecovBot commented Sep 19, 2025•
edited
Loading