Skip to content

(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

Merged
merged 6 commits into from
Apr 29, 2025

Conversation

carlaKC
Copy link
Contributor

@carlaKC carlaKC commented Apr 2, 2025

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

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Apr 2, 2025

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@carlaKC carlaKC changed the title Add Failure Reason to HTLCHandlingFailed (3/3) Add Failure Reason to HTLCHandlingFailed Apr 2, 2025
@carlaKC carlaKC force-pushed the 3541-api-changes branch 2 times, most recently from d049301 to 6138779 Compare April 4, 2025 20:36
Copy link

codecov bot commented Apr 11, 2025

Codecov Report

Attention: Patch coverage is 86.55462% with 32 lines in your changes missing coverage. Please review.

Project coverage is 89.60%. Comparing base (0ee1def) to head (5badb5e).
Report is 23 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/events/mod.rs 10.71% 25 Missing ⚠️
lightning/src/ln/channelmanager.rs 90.24% 4 Missing ⚠️
lightning-liquidity/src/lsps2/service.rs 0.00% 2 Missing ⚠️
lightning/src/ln/monitor_tests.rs 83.33% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@valentinewallace
Copy link
Contributor

Needs rebase 🥳

@carlaKC carlaKC marked this pull request as ready for review April 17, 2025 19:24
@joostjager joostjager requested review from joostjager and removed request for wpaulino April 17, 2025 19:53
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@carlaKC
Copy link
Contributor Author

carlaKC commented Apr 21, 2025

Pushed suggested comment/style changes + rename of HTLCFailReasonRepr to go with outer struct rename.

Happy to drop the last two commits as discussed here if the renames aren't strong enough to justify the change!

Comment on lines +532 to +542
Downstream,
/// The HTLC was failed locally by our node.
Local {
/// The reason that our node chose to fail the HTLC.
reason: LocalHTLCFailureReason,
},
Copy link
Contributor

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.

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 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.

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Noted in #3753.

@@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

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..

@carlaKC
Copy link
Contributor Author

carlaKC commented Apr 23, 2025

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.

@carlaKC carlaKC requested a review from joostjager April 24, 2025 12:35
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.

Nothing blocking if we want to Just Land and save the ser tweak for follow-up

Comment on lines 1809 to 1818
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()
};
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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).

carlaKC added a commit to carlaKC/rust-lightning that referenced this pull request Apr 26, 2025
carlaKC added a commit to carlaKC/rust-lightning that referenced this pull request Apr 26, 2025
joostjager
joostjager previously approved these changes Apr 28, 2025
Copy link
Contributor

@joostjager joostjager left a 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) => {},
Copy link
Contributor

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.

Copy link
Contributor

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.

@valentinewallace
Copy link
Contributor

LGTM, feel free to squash IMO

carlaKC added 6 commits April 28, 2025 15:43
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.
@carlaKC
Copy link
Contributor Author

carlaKC commented Apr 28, 2025

Squashed + fixed up some commit messages that still said HtlcHandlingType instead of HTLCHandlingFailureType, no code diff.

@carlaKC
Copy link
Contributor Author

carlaKC commented Apr 29, 2025

Taking a look at fuzzing failure!

@carlaKC
Copy link
Contributor Author

carlaKC commented Apr 29, 2025

Pretty sure that fuzzing failure is unrelated because:

  1. Input fails on main as well as feature branch
  2. Channel monitor isn't touched in this PR + error looks totally unrelated

Details of failure in #3756, would appreciate a second set of eyes to confirm 🙏

@valentinewallace
Copy link
Contributor

Landing because per #3756 (comment) the fuzz failure is unrelated

@valentinewallace valentinewallace merged commit 6f065ba into lightningdevkit:main Apr 29, 2025
25 of 27 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.

Add a reason enum to HTLCDestination in some variants Give HTLCHandlingFailed a reason of some kind
4 participants