Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple MessageRouter from Router #3326

Merged
merged 4 commits into from
Sep 24, 2024

Conversation

jkczyz
Copy link
Contributor

@jkczyz jkczyz commented Sep 18, 2024

ChannelManager is parameterized by a Router, which must also implement MessageRouter. Instead, add a MessageRouter parameter such that the Router and MessageRouter traits can be de-coupled. This simplifies using something other than DefaultMessageRouter, which DefaultRouter currently delegates to.

Copy link

codecov bot commented Sep 18, 2024

Codecov Report

Attention: Patch coverage is 84.31373% with 16 lines in your changes missing coverage. Please review.

Project coverage is 89.63%. Comparing base (cdd1298) to head (cad0985).
Report is 7 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/ln/channelmanager.rs 47.36% 10 Missing ⚠️
lightning/src/ln/invoice_utils.rs 90.90% 6 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3326      +/-   ##
==========================================
- Coverage   89.64%   89.63%   -0.01%     
==========================================
  Files         126      126              
  Lines      102676   102657      -19     
  Branches   102676   102657      -19     
==========================================
- Hits        92043    92020      -23     
+ Misses       7909     7907       -2     
- Partials     2724     2730       +6     
Flag Coverage Δ
89.63% <84.31%> (?)

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.

ChannelManager is parameterized by a Router, which must also implement
MessageRouter. Instead, add a MessageRouter parameter such that the
Router and MessageRouter traits can be de-coupled. This simplifies using
something other than DefaultMessageRouter, which DefaultRouter currently
delegates to.
DefaultRouter::create_blinded_payment_paths may creat a one-hop blinded
path with the recipient as the introduction node. Update the privacy
section of DefaultRouter's docs to indicate this as is done in the docs
for DefaultMessageRouter.
Now that ChannelManager is parameterized by both a MessageRouter and a
Router, Router implementations no longer need to implement
MessageRouter, too.
Copy link
Contributor

@shaavan shaavan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🚀

Comment on lines 1365 to +1366
/// - [`Router`] for finding payment paths when initiating and retrying payments
/// - [`MessageRouter`] for finding message paths when initiating and retrying onion messages
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Router, and MessageRouter are decoupled, should we consider renaming Router to PaymentRouter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think this should be considered in a follow-up PR at least. Makes sense.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines 1365 to +1366
/// - [`Router`] for finding payment paths when initiating and retrying payments
/// - [`MessageRouter`] for finding message paths when initiating and retrying onion messages
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think this should be considered in a follow-up PR at least. Makes sense.

@tnull tnull merged commit 4e1f1a8 into lightningdevkit:main Sep 24, 2024
16 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants