Parameterize `ChannelManager` by a `Router` #1812

valentinewallace · 2022-10-28T15:36:49Z

This will be used in upcoming work to fetch routes on-the-fly for trampoline payments.

It's all boilerplate.

~~Based on #1811~~
~~Based on #1862~~
~~Based on #1923~~
~~Based on #1928~~

codecov-commenter · 2022-10-28T20:44:53Z

Codecov Report

Base: 90.75% // Head: 90.75% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (04e31f1) compared to base (7d84a45).
Patch coverage: 84.14% of modified lines in pull request are covered.

❗ Current head 04e31f1 differs from pull request most recent head 9f1e473. Consider uploading reports for the commit 9f1e473 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1812      +/-   ##
==========================================
- Coverage   90.75%   90.75%   -0.01%     
==========================================
  Files          96       96              
  Lines       50082    50186     +104     
  Branches    50082    50186     +104     
==========================================
+ Hits        45453    45544      +91     
- Misses       4629     4642      +13

Impacted Files	Coverage Δ
lightning-block-sync/src/init.rs	`91.11% <ø> (ø)`
lightning/src/ln/payment_tests.rs	`98.73% <ø> (ø)`
lightning/src/ln/peer_handler.rs	`55.82% <ø> (ø)`
lightning/src/ln/priv_short_conf_tests.rs	`96.54% <ø> (ø)`
lightning/src/ln/reorg_tests.rs	`100.00% <ø> (ø)`
lightning/src/util/test_utils.rs	`71.52% <52.17%> (-1.57%)`	⬇️
lightning/src/util/ser_macros.rs	`86.98% <60.00%> (-0.30%)`	⬇️
lightning-background-processor/src/lib.rs	`95.45% <100.00%> (+0.02%)`	⬆️
lightning-invoice/src/payment.rs	`89.48% <100.00%> (ø)`
lightning-invoice/src/utils.rs	`97.76% <100.00%> (+0.74%)`	⬆️
... and 15 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

fuzz/src/chanmon_consistency.rs

lightning/src/util/test_utils.rs

lightning/src/ln/channelmanager.rs

jkczyz · 2022-11-07T19:36:40Z

Something that just came to mind, do we care that a custom router may be need to do network I/O? This would be the case for delegating to a server for routing.

valentinewallace · 2022-11-09T20:41:25Z

Something that just came to mind, do we care that a custom router may be need to do network I/O? This would be the case for delegating to a server for routing.

Oof. I guess with trampoline, we're moving towards a world where beefy LSP nodes handle routing, which arguably makes the use case less important. It does seem like a downside though

TheBlueMatt · 2022-11-09T20:58:46Z

Right, so I think it may actually be okay here - if we're doing this processing in process_pending_htlc_forwards (which I think is where we'll end up?), we can expose an async version that starts by fetching the routes it thinks its gonna need, and then goes into common sync code to actually send. This is gonna imply some changes, though, it means we'll want to take the Router, in one form or another, as an argument to process_pending_htlc_forwards (and, I guess, send), as we'll have to be able to accept both a sync and non-sync version.

TheBlueMatt · 2022-11-16T20:52:53Z

Needs rebase - I assume we're going to make the Router required explicitly now?

valentinewallace · 2022-11-16T20:54:30Z

Yeah, although do we want to put off landing this until retries is closer?

TheBlueMatt · 2022-11-16T20:57:56Z

Yea, that sounds good to me, just checking to make sure you're not waiting on something here.

valentinewallace · 2022-12-22T15:19:06Z

Moved two more commits over from #1916

jkczyz · 2022-12-23T23:28:10Z

lightning/src/util/test_utils.rs

-pub struct TestRouter {}
+pub struct TestRouter<'a> {
+	pub network_graph: Arc<NetworkGraph<&'a TestLogger>>,
+}
+
+impl<'a> TestRouter<'a> {
+	pub fn new(network_graph: Arc<NetworkGraph<&'a TestLogger>>) -> Self {
+		Self { network_graph }
+	}
+}


Any reason why we don't use DefaultRouter like elsewhere? Could possibly type alias TestRouter to it.

It would complicate the test utils a bit because we'd need to also have a scorer. Can file an issue for follow-up if you prefer

jkczyz · 2022-12-24T00:27:17Z

lightning/src/ln/channelmanager.rs

+	Arc<DefaultRouter<
+		Arc<NetworkGraph<Arc<L>>>,
+		Arc<L>,
+		Arc<Mutex<ProbabilisticScorer<Arc<NetworkGraph<Arc<L>>>, Arc<L>>>>
+	>>,


What's the reason for specifying a router if we don't specify, say, a chain::Watch as ChainMonitor? More generally, when should we specify a parameterization here vs leaving the choice to the user?

I don't see an issue with parameterizing by ChainMonitor and taking a Persist in Simple*ChanMan instead. If a good candidate for parameterization exists, seems like we should use it.

Hmm... I think the idea for this type alias is to simply using Arcs not necessarily defining reasonable defaults. Then again, it's already parameterized with a KeysManager. 🤷‍♂️ At very least the docs should be updated accordingly. Just seems any such alias should be defined at a higher level if we are going to be opinionated. Or have another alias like DefaultArcChannelManager or the like.

Ah, I'd always interpreted it as a Simple manager that picks defaults for things you Definitely want to Just Use, and leaves the rest up to you. If we are just adding Arcs I'm not really sure its worth defining a public type alias?

I guess the docs aren't super clear. It says "Defining these type aliases prevents issues such as overly long function definitions." And then goes on to state that KeysManager was chosen as a concrete type. But we don't do the same with ChainMonitor. We can have define the aliases for whatever reason we want, of course. Just looking for some consistency. Changing it may break users, though, if they are relying on it for their own parameterization, which is probably a low probability and can be easily fixed with their own alias.

Updated the docs. Browsing the git blame, I think the ChainMonitor not being specified may be a legacy thing and could be updated for consistency (probably not in this PR though)

lightning/src/util/ser_macros.rs

lightning/src/util/test_utils.rs

jkczyz · 2022-12-24T01:32:54Z

lightning/src/util/test_utils.rs

+	pub fn set_next_update_ret(&self, next_ret: chain::ChannelMonitorUpdateStatus) {
+		self.update_rets.lock().unwrap().push_back(next_ret);
 	}


Is the change in semantics here intentional? Previously, only calling set_next_update_ret would result in first returning Completed and then repeatedly returning next_ret. Now, it results in repeatedly returning next_ret only.

Not really intentional, the intention was to make this util support the tests added in #1916 while still supporting existing tests

TheBlueMatt · 2023-01-03T19:28:22Z

Needs rebase, sadly, should be super trivial, though.

This will be used in upcoming work to fetch routes on-the-fly for payment retries, which will no longer be the responsibility of InvoicePayer.

valentinewallace · 2023-01-03T20:41:03Z

Rebased

TheBlueMatt · 2023-01-03T23:22:24Z

Oops, CI is mad, I think its a conflict with #1934

lightning/src/util/test_utils.rs

jkczyz · 2023-01-05T03:34:30Z

lightning/src/ln/channelmanager.rs

+	Arc<DefaultRouter<
+		Arc<NetworkGraph<Arc<L>>>,
+		Arc<L>,
+		Arc<Mutex<ProbabilisticScorer<Arc<NetworkGraph<Arc<L>>>, Arc<L>>>>
+	>>,


Hmm... I think the idea for this type alias is to simply using Arcs not necessarily defining reasonable defaults. Then again, it's already parameterized with a KeysManager. 🤷‍♂️ At very least the docs should be updated accordingly. Just seems any such alias should be defined at a higher level if we are going to be opinionated. Or have another alias like DefaultArcChannelManager or the like.

jkczyz · 2023-01-05T03:41:36Z

lightning/src/util/test_utils.rs

-	pub fn set_next_update_ret(&self, next_ret: Option<chain::ChannelMonitorUpdateStatus>) {
-		*self.next_update_ret.lock().unwrap() = next_ret;
+	/// Queue an update status to return.
+	pub fn set_update_ret(&self, next_ret: chain::ChannelMonitorUpdateStatus) {


Could you rename this push_update_ret? Would make the call sites more sensible, IMO.

Yeah, I'd rather do that in follow-up though because there are a lot of callsites

Useful in upcoming work when for payment retries.

This is useful in the type serialization definition macros to avoid writing or reading a field at all, simply using a static value on each reload.

.. to disamgibutate from check_encoded_tlv_order

jkczyz

Happy to merge as is and do any follow-ups later.

TheBlueMatt

First comment can just be fixed in a later PR, second one needs a followup.

TheBlueMatt · 2023-01-05T20:06:04Z

lightning/src/ln/channelmanager.rs

 	/// force-closed during deserialization.
 	pub tx_broadcaster: T,
+	/// The router which will be used in the ChannelManager in the future for finding routes
+	/// on-the-fly for trampoline payments. Absent in private nodes that don't support forwarding.


This last sentence isn't true anymore.

TheBlueMatt · 2023-01-05T22:07:32Z

lightning/src/util/test_utils.rs

-	/// If this is set to Some(), after the next return, we'll always return this until update_ret
-	/// is changed:
-	pub next_update_ret: Mutex<Option<chain::ChannelMonitorUpdateStatus>>,
+	/// The queue of update statuses we'll return. If none are queued, ::Completed will always be


This makes our tests very brittle - if something changes which causes us to persist an extra monitor because of some commitment-update-ordering or batching changes, suddenly we'll run out of monitor update results and the test behavior will change. Instead, we should consider tracking whether monitor update status results were set at all, and if they were, panic if we try to get a result and no results are available, and also panic on Drop if results were not completely used.

Instead, we should consider tracking whether monitor update status results were set at all, and if they were, panic if we try to get a result and no results are available

To confirm, the goal with this would be to force tests to explicitly adapt to e.g. a new monitor update rather than having their behavior silently change?

Right, a test must either (a) never call set_update_ret or (b) call it exact the same number of times as there are persistence events.

Hmm, so that causes 30 test failures. They don't look too difficult, but I hadn't realized how deep this refactor was and I think I can rewrite the tests to avoid needing it more easily than complete it. Thoughts on reverting this commit?

I'm okay with that, too. I mean I do think this commit cleaned up the test util here, and the above suggestions would clean it up even more, but if we really don't want to go down that path we can walk it back.

Okay, I'll probably go through with the refactor in parallel to #1916 then. May not be able to follow up on this until sometime next week.

valentinewallace added the blocked on dependent pr label Oct 28, 2022

valentinewallace force-pushed the 2022-10-chanman-router-param branch from 2007c48 to 8c2e3f0 Compare October 28, 2022 15:45

jkczyz self-requested a review October 28, 2022 16:45

valentinewallace force-pushed the 2022-10-chanman-router-param branch from 8c2e3f0 to 2a8d727 Compare October 28, 2022 20:25

valentinewallace marked this pull request as draft October 28, 2022 20:28

valentinewallace force-pushed the 2022-10-chanman-router-param branch 3 times, most recently from 988459a to e5a793d Compare November 1, 2022 01:12

valentinewallace marked this pull request as ready for review November 1, 2022 15:45

valentinewallace force-pushed the 2022-10-chanman-router-param branch from e5a793d to e1e7053 Compare November 4, 2022 15:14

valentinewallace added Seeking Code Review and removed blocked on dependent pr labels Nov 4, 2022

TheBlueMatt reviewed Nov 4, 2022

View reviewed changes

fuzz/src/chanmon_consistency.rs Outdated Show resolved Hide resolved

lightning/src/util/test_utils.rs Outdated Show resolved Hide resolved

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

valentinewallace removed the Seeking Code Review label Nov 7, 2022

valentinewallace force-pushed the 2022-10-chanman-router-param branch from e1e7053 to 965c435 Compare November 9, 2022 17:50

valentinewallace force-pushed the 2022-10-chanman-router-param branch 2 times, most recently from cc18702 to f5f4980 Compare November 29, 2022 22:33

TheBlueMatt mentioned this pull request Nov 29, 2022

Prepare for Payment Retries in ChannelManager #1862

Merged

TheBlueMatt added the blocked on dependent pr label Dec 1, 2022

valentinewallace added the blocked on next release Should Wait Until Next Release To Land label Dec 1, 2022

valentinewallace force-pushed the 2022-10-chanman-router-param branch from f5f4980 to 48f718f Compare December 7, 2022 01:51

valentinewallace removed the blocked on dependent pr label Dec 7, 2022

valentinewallace mentioned this pull request Dec 13, 2022

ChannelManager Payment Retries #1916

Merged

1 task

TheBlueMatt added the Seeking Code Review label Dec 21, 2022

valentinewallace force-pushed the 2022-10-chanman-router-param branch from 4d33002 to c116cd4 Compare December 22, 2022 15:16

valentinewallace force-pushed the 2022-10-chanman-router-param branch from c116cd4 to dc8cfea Compare December 22, 2022 16:43

TheBlueMatt removed the Seeking Code Review label Dec 22, 2022

TheBlueMatt assigned TheBlueMatt and jkczyz Dec 22, 2022

jkczyz reviewed Dec 24, 2022

View reviewed changes

valentinewallace force-pushed the 2022-10-chanman-router-param branch from dc8cfea to fde0555 Compare January 3, 2023 16:35

Parameterize ChannelManager by a Router trait

2e06efe

This will be used in upcoming work to fetch routes on-the-fly for payment retries, which will no longer be the responsibility of InvoicePayer.

valentinewallace force-pushed the 2022-10-chanman-router-param branch from fde0555 to 902b70c Compare January 3, 2023 20:39

valentinewallace force-pushed the 2022-10-chanman-router-param branch from 902b70c to 04e31f1 Compare January 4, 2023 16:10

valentinewallace requested a review from jkczyz January 4, 2023 17:04

valentinewallace force-pushed the 2022-10-chanman-router-param branch from 04e31f1 to 9f1e473 Compare January 4, 2023 17:50

jkczyz reviewed Jan 5, 2023

View reviewed changes

valentinewallace and others added 6 commits January 5, 2023 11:23

Implement routing against the netgraph in tests

3a274e0

Take in-flight HTLCs by reference in Router::find_route

3a1982c

Useful in upcoming work when for payment retries.

Parameterize Simple*ChannelManager with DefaultRouter and ProbScorer

682bb9b

Provide a static_value TLV field serialization type

af6fa14

This is useful in the type serialization definition macros to avoid writing or reading a field at all, simply using a static value on each reload.

ser_macros: rename check_tlv_order

22501c3

.. to disamgibutate from check_encoded_tlv_order

Test utils: allow queueing >2 persistence update results

19516c0

valentinewallace force-pushed the 2022-10-chanman-router-param branch from 9f1e473 to 19516c0 Compare January 5, 2023 16:29

jkczyz approved these changes Jan 5, 2023

View reviewed changes

TheBlueMatt approved these changes Jan 5, 2023

View reviewed changes

TheBlueMatt merged commit b79ff71 into lightningdevkit:main Jan 5, 2023

TheBlueMatt mentioned this pull request Jan 5, 2023

Remove KeysInterface #1930

Merged

Parameterize ChannelManager by a Router #1812

Parameterize ChannelManager by a Router #1812

Uh oh!

Conversation

valentinewallace commented Oct 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov-commenter commented Oct 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkczyz commented Nov 7, 2022

Uh oh!

valentinewallace commented Nov 9, 2022

Uh oh!

TheBlueMatt commented Nov 9, 2022

Uh oh!

TheBlueMatt commented Nov 16, 2022

Uh oh!

valentinewallace commented Nov 16, 2022

Uh oh!

TheBlueMatt commented Nov 16, 2022

Uh oh!

valentinewallace commented Dec 22, 2022

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!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt commented Jan 3, 2023

Uh oh!

valentinewallace commented Jan 3, 2023

Uh oh!

TheBlueMatt commented Jan 3, 2023

Uh oh!

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!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt 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!

Parameterize `ChannelManager` by a `Router` #1812

Parameterize `ChannelManager` by a `Router` #1812

valentinewallace commented Oct 28, 2022 •

edited

Loading

codecov-commenter commented Oct 28, 2022 •

edited

Loading