-
Notifications
You must be signed in to change notification settings - Fork 405
(3/3) Add Failure Reason to HTLCHandlingFailed #3700
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
(3/3) Add Failure Reason to HTLCHandlingFailed #3700
Conversation
👋 Thanks for assigning @joostjager as a reviewer! |
d049301
to
6138779
Compare
6138779
to
2d39ef8
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3700 +/- ##
==========================================
+ Coverage 89.13% 89.60% +0.46%
==========================================
Files 156 158 +2
Lines 123600 127663 +4063
Branches 123600 127663 +4063
==========================================
+ Hits 110176 114390 +4214
+ Misses 10757 10640 -117
+ Partials 2667 2633 -34 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
2d39ef8
to
b48c6ce
Compare
Needs rebase 🥳 |
b48c6ce
to
cda8de5
Compare
🔔 1st Reminder Hey @valentinewallace! This PR has been waiting for your review. |
cda8de5
to
6638118
Compare
Pushed suggested comment/style changes + rename of Happy to drop the last two commits as discussed here if the renames aren't strong enough to justify the change! |
Downstream, | ||
/// The HTLC was failed locally by our node. | ||
Local { | ||
/// The reason that our node chose to fail the HTLC. | ||
reason: LocalHTLCFailureReason, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if it would be nicer to avoid this outer enum and just document on the field "Will be None if the HTLC failed downstream or this event was created prior to 0.2." Seems simpler, loses a bit of information for a period of time though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it would be nice to surface hold_time
along with Downstream
in future (nice thing to put on a dashboard IMO) so tend towards keeping the enum for the sake of being able to easily add that.
Opinion not very strongly held though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't realize that was a potential goal but that makes sense! We may want to document this on the attributable failures issue, if there is one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joostjager do we have a tracking issue for follow-ups for attributable failures? IIRC we still need to support the hold_times
part of the spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted in #3753.
lightning/src/events/mod.rs
Outdated
@@ -480,12 +480,16 @@ pub enum HTLCHandlingType { | |||
channel_id: ChannelId, | |||
}, | |||
/// Scenario where we are unsure of the next node to forward the HTLC to. | |||
/// | |||
/// Deprecated: will only be used in versions before LDK v0.2.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can use the official deprecated
attribute on this: https://doc.rust-lang.org/reference/attributes/diagnostics.html#r-attributes.diagnostics.deprecated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL this exists!
Struggling to #[allow(deprecated)]
for the impl_writeable_tlv_based_enum_upgradable
invocation to silence the cargo warning though..
6638118
to
c78304f
Compare
Removed the last 2 rename commits (I don't think they're that much of an improvement) + fixed up comment. Couldn't find a way to use deprecation attribute without making changes to the serialization macro so left it out. |
c78304f
to
51eb743
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing blocking if we want to Just Land and save the ser tweak for follow-up
lightning/src/events/mod.rs
Outdated
let downgradable_type = match (failure_type, failure_reason) { | ||
(HTLCHandlingFailureType::InvalidForward { requested_forward_scid }, | ||
Some(HTLCHandlingFailureReason::Local { | ||
reason: LocalHTLCFailureReason::UnknownNextPeer | ||
})) | ||
=> HTLCHandlingFailureType::UnknownNextHop { | ||
requested_forward_scid: *requested_forward_scid, | ||
}, | ||
_ => failure_type.clone() | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies if I signed off on this previously, but I think it would make more sense to always write the non-deprecated type and then include a release note that downgrades will result in reading the deprecated type as ::InvalidForward
, since it'll save some complexity here and keep the door open for us to delete the variant in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having done it this way, I think it looks much better 👍 doesn't seem like that much of a loss to have less information on downgrade in comparison
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there no functional consequences after the downgrade for this loss of information?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
afaik no, HTLCHandlingFailed
is a "read-only" event - it doesn't require any action from an end user.
So worst case it's a few wrong entries in a tracking dashboard, but I think the release note is sufficient to highlight that (so that downgraders are aware).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
} | ||
|
||
impl_writeable_tlv_based_enum!(HTLCHandlingFailureReason, | ||
(1, Downstream) => {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't those be even because it is a completely new type? I somehow feel that we've been here before, but maybe it was another PR. Enum always odd regardless, was that the outcome? Doesn't seem to matter all that much though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Odd/even enum variant types only have different behavior in impl_writeable_tlv_based_enum_upgradable
:) We could use that macro instead if we think we'll want to add more odd variants in the future, though I don't feel strongly about that because that doesn't seem likely IMO.
5badb5e
to
ed5210d
Compare
LGTM, feel free to squash IMO |
HTLCDestination currently contains a combination of information about the type of HTLC we handled to fail (a payment, a forward etc) and error information for a select set of cases (unknown next peer, for example). In preparation for a refactor that will split the failure reason out into its own enum, this commit renames HTLCDestination to HTLCHandlingFailureType.
Rename variant to be more specific to the current context - a FailedPayment could be a payment that we failed to dispatch or one that we rejected on receive.
Standardize naming within the HTLCHandlingFailureType struct to present more consistent API terminology.
This variant of HTLCHandlingFailureType contains information about the failure cause along with its type - as an UnknownNextPeer is just an InvalidForward that has the failure type UnknownNextPeer. Use of the variant is deprecated, and any old events are upgraded to the new representation. As a result, downgrading nodes will get an InvalidForward where they otherwise would have had an UnknownNextPeer. The alternative would be to continue to write the old representation to prevent this information loss on downgrade, but it comes at the cost of not being able to remove the UnknownNextPeer variant in future (and some extra handling code). The deprecated attribute is not used because it cannot be silenced in impl_writeable_tlv_based_enum, which uses UnknownNextPeer to remain downgradable.
ed5210d
to
af301f4
Compare
Squashed + fixed up some commit messages that still said |
Taking a look at fuzzing failure! |
Pretty sure that fuzzing failure is unrelated because:
Details of failure in #3756, would appreciate a second set of eyes to confirm 🙏 |
Landing because per #3756 (comment) the fuzz failure is unrelated |
6f065ba
into
lightningdevkit:main
This PR surfaces a failure reason in
HTLCHandlingFailed
events. Opening up early to add some context to the prefactor PR #3601.The heart of the PR is in d35d35f, and it could probably be reduced to just this commit. I've made some quite opinionated renaming / deprecation decisions in the other commits which aren't required for this change, but I think make for a more readable API overall - happy to drop them if it ain't broke, don't fix it applies.
Fixes: #3561
Fixes: #3541