Skip to content

(3/3) Add Failure Reason to HTLCHandlingFailed - #3700

Merged
valentinewallace merged 6 commits into
lightningdevkit:mainfrom
carlaKC:3541-api-changes
Apr 29, 2025
Merged

(3/3) Add Failure Reason to HTLCHandlingFailed#3700
valentinewallace merged 6 commits into
lightningdevkit:mainfrom
carlaKC:3541-api-changes

Conversation

@carlaKC

@carlaKCcarlaKC commented Apr 2, 2025

Copy link
Copy Markdown
Contributor

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

ldk-reviews-bot commented Apr 2, 2025

Copy link
Copy Markdown

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

@carlaKCcarlaKC changed the title Add Failure Reason to HTLCHandlingFailed(3/3) Add Failure Reason to HTLCHandlingFailedApr 2, 2025
@carlaKC
carlaKCforce-pushed the 3541-api-changes branch 2 times, most recently from d049301 to 6138779CompareApril 4, 2025 20:36
Comment threadlightning/src/events/mod.rs
@valentinewallacevalentinewallace mentioned this pull request Apr 10, 2025
4 tasks
@codecov

codecovBot commented Apr 11, 2025

Copy link
Copy Markdown

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 linesPatch %Lines
lightning/src/events/mod.rs10.71%25 Missing ⚠️
lightning/src/ln/channelmanager.rs90.24%4 Missing ⚠️
lightning-liquidity/src/lsps2/service.rs0.00%2 Missing ⚠️
lightning/src/ln/monitor_tests.rs83.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
Copy Markdown
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 wpaulinoApril 17, 2025 19:53
Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs
Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs
Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/ln/onion_utils.rs Outdated
@ldk-reviews-bot

Copy link
Copy Markdown

🔔 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
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Noted in #3753.

Comment threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs Outdated
},
/// 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
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
ContributorAuthor

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 joostjagerApril 24, 2025 12:35
Comment threadlightning/src/events/mod.rs Outdated
valentinewallace
valentinewallace previously approved these changes Apr 25, 2025

@valentinewallacevalentinewallace left a comment

Copy link
Copy Markdown
Contributor

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 threadlightning/src/events/mod.rs Outdated
Comment threadlightning/src/events/mod.rs Outdated
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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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
Copy Markdown
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
Copy Markdown
ContributorAuthor

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

Comment threadlightning/src/events/mod.rs Outdated
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

@joostjagerjoostjager left a comment

Copy link
Copy Markdown
Contributor

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

Comment threadlightning/src/events/mod.rs Outdated
Comment threadpending_changelog/3700-reason-in-handling-failed.txt
@valentinewallace

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
ContributorAuthor

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

@carlaKC

Copy link
Copy Markdown
ContributorAuthor

Taking a look at fuzzing failure!

@carlaKC

Copy link
Copy Markdown
ContributorAuthor

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
Copy Markdown
Contributor

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

Sign up for freeto 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

@carlaKC@ldk-reviews-bot@valentinewallace@joostjager