Do not always persist ChannelManager on channel_update messages by TheBlueMatt · Pull Request #972 · lightningdevkit/rust-lightning

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt · 2021-06-28T00:56:45Z

Based on #965 as it fixes a bug which would make this PR useless.

If we receive a channel_update message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
ChannelManager. This avoids significant persistence traffic during
initial node startup.

codecov · 2021-06-28T01:18:23Z

Codecov Report

Merging #972 (803da87) into main (f472907) will decrease coverage by 0.10%.
The diff coverage is 94.73%.

@@ Coverage Diff @@## main #972 +/- ##
==========================================
- Coverage 90.63% 90.52% -0.11% 
==========================================
Files 60 60 Lines 30538 30654 +116 ==========================================
+ Hits 27678 27750 +72 - Misses 2860 2904 +44

Impacted Files	Coverage Δ
lightning/src/ln/peer_handler.rs	`46.73% <ø> (ø)`
lightning/src/ln/channelmanager.rs	`84.69% <94.59%> (+0.79%)`	⬆️
lightning/src/ln/channel.rs	`88.51% <100.00%> (ø)`
lightning/src/util/events.rs	`15.15% <0.00%> (-2.15%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.21% <0.00%> (+0.04%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f472907...803da87. Read the comment docs.

valentinewallace

Unit test would be cool if it's easy, otherwise LGTM

valentinewallace · 2021-06-30T03:21:16Z

+ let node_b_chan_info = nodes[1].node.list_channels()[0].clone();
+
+ // The first two nodes (which opened a channel) should now require fresh persistence
+ assert!(nodes[0].node.await_persistable_update_timeout(Duration::from_millis(1)));


Not sure if by design, but don't think this test covers the DoPersist case: https://i.imgur.com/7fAhVOh.png

I'm not sure what I'm looking at there, but if not that's a bug - await_persistable_update_timeout is supposed to return true only if we have a reason to persist.

Just meant that the test doesn't cover the case where we do want to persist after handling a channel update

Right, yes, sorry. As I was writing the test I found another bug, so the test is finished in the last commit at #949.

If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

TheBlueMatt · 2021-06-30T16:14:20Z

Squashed without diff:

$ git diff-tree -U1 b7d249ab 803da875
$

jkczyz · 2021-06-30T20:18:25Z


 /// Information needed for constructing an invoice route hint for this channel.
-#[derive(Clone)]
+#[derive(Clone, Debug, PartialEq)]


Instead of implementing PartialEq, test that fee_base_msat hasn't changed.

I think its generally a good thing to have either way - its a public struct and its reasonable for users to want to compare it? If you disagree we can change it in a followup.

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

TheBlueMatt added this to the 0.0.99 milestone Jun 28, 2021

valentinewallace reviewed Jun 29, 2021
View reviewed changes

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from f7acf9e to e5dd416Compare June 29, 2021 21:55

TheBlueMatt mentioned this pull request Jun 30, 2021
Send channel_update messages to direct peers on private channels #949
Merged

valentinewallace reviewed Jun 30, 2021
View reviewed changes

Comment threadlightning/src/ln/channelmanager.rs

valentinewallace approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt added 2 commits June 30, 2021 16:13

Do not always persist ChannelManager on channel_update messages
eca6da3
If we receive a `channel_update` message for a channel unrelated to our own, we shouldn't trigger a persistence of our `ChannelManager`. This avoids significant persistence traffic during initial node startup.

Fix unused import in peer_handler introduced in1f592b0
803da87

TheBlueMatt force-pushed the 2021-06-skip-notify-chansync branch from b7d249a to 803da87Compare June 30, 2021 16:13

jkczyz approved these changes Jun 30, 2021
View reviewed changes

TheBlueMatt merged commit 57e813f into lightningdevkit:mainJun 30, 2021

Uh oh!

Conversation

TheBlueMatt commented Jun 28, 2021

Uh oh!

codecovBot commented Jun 28, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

valentinewallace left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheBlueMatt commented Jun 30, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMattJun 30, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Jun 28, 2021

Uh oh!

codecovBot commented Jun 28, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

valentinewallace left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheBlueMatt commented Jun 30, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMattJun 30, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Jun 28, 2021

Uh oh!

codecovBot commented Jun 28, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

codecovBot commented Jun 28, 2021•
edited
Loading

TheBlueMattJun 30, 2021•
edited
Loading

codecovBot commented Jun 28, 2021•
edited
Loading

TheBlueMattJun 30, 2021•
edited
Loading

codecovBot commented Jun 28, 2021•
edited
Loading

TheBlueMattJun 30, 2021•
edited
Loading

codecovBot commented Jun 28, 2021•
edited
Loading