Further decouple ChannelManager from Channel state somewhat by TheBlueMatt · Pull Request #3539 · lightningdevkit/rust-lightning

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

TheBlueMatt · 2025-01-15T01:19:15Z

Just a few tiny followups to #3513 to keep moving towards ChannelManager caring less about the specific state the channel is in.

jkczyz · 2025-01-15T17:45:16Z

+	/// Should be called when the peer is disconnected. Returns true if the channel can be resumed
+	/// when the peer reconnects (via [`Self::peer_connected_get_handshake`]). If not, the channel
+	/// must be immediately closed.
+	pub fn peer_disconnected_is_resumable<L: Deref>(&mut self, logger: &L) -> bool where L::Target: Logger {


How about naming this is_disconnected_peer_resumable?

Its not stateless, though, I wanted to communicate that its a "this peer has disconnected" notification, plus "should i discard the channel". Not sure how best to communicate it, this name is a bit awkward.

wpaulino · 2025-01-16T22:08:15Z

LGTM once the logging context is restored

TheBlueMatt · 2025-01-24T22:09:55Z

Sorry for the delay, fixed the logger issue:

$ git diff-tree -U2 e25da1455 2abe8469b
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index fcc11ca05..16599f126 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -9455,6 +9455,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// Returns whether we should remove this channel as it's just been closed.
let unblock_chan = |phase: &mut Channel<SP>, pending_msg_events: &mut Vec<MessageSendEvent>| -> Option<ShutdownResult> {
+ let logger = WithChannelContext::from(&self.logger, &phase.context(), None);
let node_id = phase.context().get_counterparty_node_id();
- if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &self.logger) {+ if let Some(msgs) = phase.signer_maybe_unblocked(self.chain_hash, &&logger) {
if let Some(msg) = msgs.open_channel {
pending_msg_events.push(events::MessageSendEvent::SendOpenChannel {
@@ -9513,7 +9514,4 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
}
if let Some(broadcast_tx) = msgs.signed_closing_tx {
- let channel_id = chan.context.channel_id();- let counterparty_node_id = chan.context.get_counterparty_node_id();- let logger = WithContext::from(&self.logger, Some(counterparty_node_id), Some(channel_id), None);
log_info!(logger, "Broadcasting closing tx {}", log_tx!(broadcast_tx));
self.tx_broadcaster.broadcast_transactions(&[&broadcast_tx]);

jkczyz · 2025-01-27T16:09:07Z

FYI, this will conflict with #3550. May be easier to get that in first, but either way is fine by me.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when unblocking the signer.

TheBlueMatt · 2025-01-27T21:44:12Z

Rebased.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer disconnects.

After lightningdevkit#3513 we have a bit more encapsulation of channel logic in channel.rs with channelmanager.rs needing a bit less knowledge of which specific state a channel is in. This continues that trend slightly when a peer reconnects.

TheBlueMatt · 2025-01-28T14:49:15Z

Ugh, fixed the dangling link after the third commit.

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

jkczyz self-requested a review January 15, 2025 17:34

jkczyz reviewed Jan 15, 2025
View reviewed changes

TheBlueMatt force-pushed the 2025-01-3513-followups branch from e25da14 to 2abe846Compare January 24, 2025 22:09

TheBlueMatt added 2 commits January 27, 2025 21:35

Remove redundant variable
695c612

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 2abe846 to 6852e8aCompare January 27, 2025 21:44

wpaulino approved these changes Jan 27, 2025
View reviewed changes

jkczyz reviewed Jan 27, 2025
View reviewed changes

Comment threadlightning/src/ln/channel.rs

TheBlueMatt added 2 commits January 28, 2025 14:48

TheBlueMatt force-pushed the 2025-01-3513-followups branch from 6852e8a to bece44cCompare January 28, 2025 14:49

jkczyz approved these changes Jan 28, 2025
View reviewed changes

wpaulino merged commit 569f906 into lightningdevkit:mainJan 28, 2025

Uh oh!

Conversation

TheBlueMatt commented Jan 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wpaulino commented Jan 16, 2025

Uh oh!

TheBlueMatt commented Jan 24, 2025

Uh oh!

jkczyz commented Jan 27, 2025

Uh oh!

TheBlueMatt commented Jan 27, 2025

Uh oh!

Uh oh!

TheBlueMatt commented Jan 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Jan 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wpaulino commented Jan 16, 2025

Uh oh!

TheBlueMatt commented Jan 24, 2025

Uh oh!

jkczyz commented Jan 27, 2025

Uh oh!

TheBlueMatt commented Jan 27, 2025

Uh oh!

Uh oh!

TheBlueMatt commented Jan 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Jan 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wpaulino commented Jan 16, 2025

Uh oh!

TheBlueMatt commented Jan 24, 2025

Uh oh!

jkczyz commented Jan 27, 2025

Uh oh!

TheBlueMatt commented Jan 27, 2025

Uh oh!

Uh oh!

TheBlueMatt commented Jan 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects