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

Abstract ChannelManager outbound payment logic #1923

Conversation

valentinewallace
Copy link
Contributor

Moves ChannelManager outbound payment logic into its own module, in preparation for payment retries.

Just code moves mostly. I kept the serialization changes surgical but we could probably move more logic there too.

@codecov-commenter
Copy link

codecov-commenter commented Dec 18, 2022

Codecov Report

Base: 90.73% // Head: 91.46% // Increases project coverage by +0.73% 🎉

Coverage data is based on head (77e2014) compared to base (56afbf5).
Patch coverage: 90.22% of modified lines in pull request are covered.

❗ Current head 77e2014 differs from pull request most recent head afdaa64. Consider uploading reports for the commit afdaa64 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1923      +/-   ##
==========================================
+ Coverage   90.73%   91.46%   +0.73%     
==========================================
  Files          94       96       +2     
  Lines       49603    53540    +3937     
  Branches    49603    53540    +3937     
==========================================
+ Hits        45006    48969    +3963     
+ Misses       4597     4571      -26     
Impacted Files Coverage Δ
lightning/src/ln/mod.rs 95.00% <ø> (ø)
lightning/src/ln/outbound_payment.rs 89.18% <89.18%> (ø)
lightning/src/ln/channelmanager.rs 86.68% <100.00%> (-0.03%) ⬇️
lightning/src/ln/reorg_tests.rs 100.00% <0.00%> (ø)
lightning/src/offers/refund.rs 93.73% <0.00%> (ø)
lightning/src/ln/monitor_tests.rs 99.84% <0.00%> (+0.27%) ⬆️
lightning/src/offers/offer.rs 93.91% <0.00%> (+0.46%) ⬆️
lightning/src/ln/payment_tests.rs 99.30% <0.00%> (+0.55%) ⬆️
lightning/src/chain/onchaintx.rs 95.38% <0.00%> (+0.83%) ⬆️
... and 5 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.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

Nice!

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@dunxen dunxen left a comment

Choose a reason for hiding this comment

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

The moves and renames LGTM!

lightning/src/ln/mod.rs Outdated Show resolved Hide resolved
@jkczyz jkczyz self-requested a review December 19, 2022 19:04
We want to move all outbound payment-related things to this new module, to help
break up ChannelManager so future payment retries work doesn't increase the
size of ChannelManager.
And re-export it in channelmanager.rs so it can remain public
dunxen
dunxen previously approved these changes Dec 19, 2022
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved
lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
@valentinewallace
Copy link
Contributor Author

Lmk when I can squash, @jkczyz

Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

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

Feel free to squash

lightning/src/ln/outbound_payment.rs Outdated Show resolved Hide resolved
This allows us to move a lot of outbound payment logic out of ChannelManager
and into the new outbound_payment module, and helps avoid growing
ChannelManager when we add retry logic to it in upcoming work.
Separating out this commit to keep the main refactor move-only
Once ChannelManager supports payment retries, it will make more sense for its
current send_payment method to be named send_payment_with_route because
retrying should be the default. Here we get a head start on this by making the
rename in outbound_payment, but not changing the public interface yet.
Copy link
Contributor

@dunxen dunxen left a comment

Choose a reason for hiding this comment

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

The commits were pretty easy to follow! Cleans up ChannelManager a load.

#[cfg(test)]
pub(crate) fn test_add_new_pending_payment(&self, payment_hash: PaymentHash, payment_secret: Option<PaymentSecret>, payment_id: PaymentId, route: &Route) -> Result<Vec<[u8; 32]>, PaymentSendFailure> {
let best_block_height = self.best_block.read().unwrap().height();
self.pending_outbound_payments.add_new_pending_payment(payment_hash, payment_secret, payment_id, route, &self.keys_manager, best_block_height)
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: should the exposure of the real add_new_pending_payment be via a test-only wrapper so that non-test channelmanager code can't call it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, it's definitely safer. Good for a follow-up.

if let hash_map::Entry::Occupied(mut payment) = outbounds.entry(*payment_id) {
if !payment.get_mut().remove(&session_priv_bytes, Some(&path)) {
log_trace!(logger, "Received duplicative fail for HTLC with payment_hash {}", log_bytes!(payment_hash.0));
return
Copy link
Collaborator

Choose a reason for hiding this comment

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

Heh, is it really worth breaking the move-only-ness to drop a ; :). Not worth fixing, really.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops, that mistakenly introduced when parameterizing the method by pending_events. I'll fix if Jeff has feedback that needs to go in this PR.

log_trace!(logger, "Failing outbound payment HTLC with payment_hash {}", log_bytes!(payment_hash.0));

let path_failure = {
#[cfg(test)]
Copy link
Collaborator

Choose a reason for hiding this comment

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

This indentation no longer makes any sense - it was left completely unindented since its a cfg (in the standard C ifdef style), but we could also put it indented like the line itself (is this standard?). It doesn't really make sense randomly indented once.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've personally seen more code where it has the same indentation as the line itself (and not ifdef style). Don't think there's a standard though.

Copy link
Contributor

Choose a reason for hiding this comment

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

Likwise, I've mostly noticed them indented.

log_trace!(logger, "Failing outbound payment HTLC with payment_hash {}", log_bytes!(payment_hash.0));

let path_failure = {
#[cfg(test)]
Copy link
Contributor

Choose a reason for hiding this comment

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

Likwise, I've mostly noticed them indented.

@@ -433,8 +435,8 @@ impl OutboundPayments {
}
}

fn send_payment_internal<K: Deref, F>
(&self, route: &Route, payment_hash: PaymentHash, payment_secret: &Option<PaymentSecret>,
fn send_payment_internal<K: Deref, F>(
Copy link
Contributor

@jkczyz jkczyz Dec 20, 2022

Choose a reason for hiding this comment

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

nit: I'd also move the closing ) to the next line here and all the following methods as you did in the methods before this (ec55730).

@valentinewallace valentinewallace merged commit e64ebe8 into lightningdevkit:main Dec 20, 2022
@valentinewallace
Copy link
Contributor Author

Will address the latest feedback in a new PR shortly!

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.

5 participants