Skip to content

Add MPP receive timeout handling #1353

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

Merged

Conversation

dunxen
Copy link
Contributor

@dunxen dunxen commented Mar 9, 2022

Closes #1050.

@@ -3234,6 +3238,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana
phantom_shared_secret,
},
value: amt_to_forward,
ticks: 0,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I should probably call this timer_ticks.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yep, probably should :)

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.

Looks basically good to me!

@@ -3234,6 +3238,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana
phantom_shared_secret,
},
value: amt_to_forward,
ticks: 0,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Yep, probably should :)

}
}

for payment_hash in &mut timed_out_payment_hashes {
Copy link
Collaborator

Choose a reason for hiding this comment

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

You should be able to use claimable_htlcs.retain() instead of iterating and removing here.

@dunxen dunxen force-pushed the 2022-03-mpp-receive-timeout branch from 37afbe4 to 5403dfb Compare March 11, 2022 17:14
@dunxen dunxen marked this pull request as ready for review March 11, 2022 17:23
@codecov-commenter
Copy link

codecov-commenter commented Mar 11, 2022

Codecov Report

Merging #1353 (daa89dd) into main (996d3d8) will increase coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head daa89dd differs from pull request most recent head 4086ce8. Consider uploading reports for the commit 4086ce8 to get more accurate results

@@            Coverage Diff             @@
##             main    #1353      +/-   ##
==========================================
+ Coverage   90.75%   90.77%   +0.01%     
==========================================
  Files          73       73              
  Lines       40979    41045      +66     
  Branches    40979    41045      +66     
==========================================
+ Hits        37191    37258      +67     
+ Misses       3788     3787       -1     
Impacted Files Coverage Δ
lightning/src/ln/channelmanager.rs 84.90% <100.00%> (+0.09%) ⬆️
lightning/src/ln/payment_tests.rs 99.23% <100.00%> (+0.07%) ⬆️

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 996d3d8...4086ce8. Read the comment docs.

@valentinewallace valentinewallace self-requested a review March 11, 2022 19:57
channel_state.claimable_htlcs.retain(|payment_hash, htlcs| {
if htlcs.into_iter().all(|htlc| {
if let OnionPayload::Invoice(ref final_hop_data) = htlc.onion_payload {
if htlc.value < final_hop_data.total_msat {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I feel like we should handle all-parts-received MPP payments and non-MPP payments the same - ie instead of just checking if this is an MPP payment here, we should check if we've actually received all the parts we need (by summing up the HTLCs for each given payment hash) before we timeout-fail parts.

This comment was marked as outdated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wait, scratch my comment. I understand now. 🤦

@dunxen dunxen force-pushed the 2022-03-mpp-receive-timeout branch 2 times, most recently from b0b3ad1 to d0369db Compare March 12, 2022 16:57
TheBlueMatt
TheBlueMatt previously approved these changes Mar 15, 2022
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.

LGTM, if you want to expand the test to also test that we dont time out if we're still waiting on parts (and that you can then receive the payment after the other parts come in) that'd be cool too.

@dunxen
Copy link
Contributor Author

dunxen commented Mar 16, 2022

LGTM, if you want to expand the test to also test that we dont time out if we're still waiting on parts (and that you can then receive the payment after the other parts come in) that'd be cool too.

Yeah, I definitely want to do that!

Copy link
Contributor

@valentinewallace valentinewallace left a comment

Choose a reason for hiding this comment

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

A few optional nits. I'm ACK after the new test changes :)

Comment on lines 3685 to 3687
} else if !htlcs.into_iter().all(|htlc| {
htlc.timer_ticks += 1;
return htlc.timer_ticks < MPP_TIMEOUT_TICKS
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: IMO avoiding double negatives is more readable
so s/!htlcs/htlcs, s/</>=

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I agree. Looks like I'd also need to change the .all() to a .any() :)

@@ -55,6 +55,8 @@ use sync::{Arc, Mutex};
use ln::functional_test_utils::*;
use ln::chan_utils::CommitmentTransaction;

use crate::ln::channelmanager::MPP_TIMEOUT_TICKS;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: s/crate:://

@dunxen
Copy link
Contributor Author

dunxen commented Mar 22, 2022

Cleaned up a little more and expanded the test to cover the success case too (also checking that timeouts don't affect when we have all parts) and rather moved the tests to payment_tests.rs to be with the other MPP stuff.

TheBlueMatt
TheBlueMatt previously approved these changes Mar 22, 2022
@@ -3668,6 +3674,28 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana

true
});

channel_state.claimable_htlcs.retain(|payment_hash, htlcs| {
if htlcs.is_empty() { return false }
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 be unreachable, maybe add a debug_assert!(false); here before the return.

@valentinewallace valentinewallace merged commit 74b9c1a into lightningdevkit:main Mar 22, 2022
@dunxen dunxen deleted the 2022-03-mpp-receive-timeout branch March 23, 2022 06:56
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.

MPP receive timeout not implemented?
4 participants