(3/3) Add Failure Reason to HTLCHandlingFailed #3700
Conversation
|
👋 Hi! I see this is a draft PR. |
carlaKC
changed the title
carlaKC
force-pushed
the
3541-api-changes
branch
2 times, most recently
from
d049301 to
6138779
Compare
| /// 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.
Thoughts on renaming LocalHTLCFailureReason to HTLCFailureReason? Then we can have Downstream just be a variant within the big enum and use the same big enum for the handling_failure field. It's a bit awkward that HTLCFailReason is another type in the codebase, but that could either be renamed to RawOnionFailure (no pun intended) or something, or punted for later.
There was a problem hiding this comment.
Then we can have Downstream just be a variant within the big enum and use the same big enum for the handling_failure field. It
Doesn't this get a bit mesy when it comes to mapping to B04 codes because Downstream wouldn't have a value?
There was a problem hiding this comment.
Ah, I was missing that. Good point indeed.
There was a problem hiding this comment.
Echo your sentiment though, sinceHTLCHandlingFailureReason is pretty much just an API-facing version of HTLCFailReason (hiding all the onion details the API doesn't care about) it is confusing to have two pretty similar structs.
Might still be worth doing a rename of HTLCFailReason?
There was a problem hiding this comment.
Yeah, I tend to agree that a rename would still be nice. Looks like ~70 occurrences of HTLCFailReason currently, I think if you're up for it then go for it!
Introduce an enum representation of BOLT04 error codes that will be introduced in the commits that follow, along with being extended to represent failures that are otherwise erased by BOLT04 error codes (insufficient liquidity which is erased by temporary channel failure, for example).
Now that we're passing around more than a BOLT04 error code, rename the field accordingly.
Now that we're not passing BOLT04 error codes around, rename the field accordingly.
Now that we're not passing around error codes, update variable names accordingly.
Update the failure reason that's persisted in HTLCFailReasonRepr to store our newly added enum, rather than the old u16. In the commits that follow, we'll add more variants create a many-to-one mapping from enum to BOLT04 code (as we're surfacing internal information that is intentionally erased by the BOLT04 codes). Without this change to persistence, we'll lose the detail that these variants contain by storing them as their erased BOLT04 code.
Sometimes the error codes that we return to the sender intentionally obscure information about the payment to prevent probing/ leaking information. This commit updates our internal representation to surface some of these failures, which will be converted to their corresponding bolt 04 codes when they're sent over the wire.
To be able to obtain the underlying error reason for the pending HTLC, break up the helper method into two parts. This also removes some unnecessary wrapping/unwrapping of messages in PendingHTLCStatus types.
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 HTLCHandlingType.
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 HTLCHandlingType struct to present more consistent API terminology.
This variant of HTLCHandlingType contains infromation about the failure cause along with its type - as an UnknownNextPeer is just an InvalidForward that has the failure type UnknownNextPeer. This commit deprecates the variant's use, while still writing it to disk to allow the option to downgrade.
This struct doesn't just contain a failure reason, it has all the data that's used to construct our failure.
carlaKC
force-pushed
the
3541-api-changes
branch
from
6138779 to
2d39ef8
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3700 +/- ##
==========================================
- Coverage 89.12% 89.09% -0.04%
==========================================
Files 156 156
Lines 123514 123670 +156
Branches 123514 123670 +156
==========================================
+ Hits 110086 110186 +100
- Misses 10749 10799 +50
- Partials 2679 2685 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This PR surfaces a failure reason in
HTLCHandlingFailedevents. Opening up early to add some context to the prefactor PR #3601.The heart of the PR is in 6df8025, 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