Use LocalHTLCFailureReason in Onion Processing #3744
Conversation
|
👋 Thanks for assigning @joostjager as a reviewer! |
|
@joostjager anything else that you'd like to add here? |
In some places where we have LocalHTLCFailureReason, the string we're passing around is redundant. This isn't the case in all uses of LocalHTLCFailureReason, for example InboundHTLCError provides additional information about payload and blinding related errors that isn't captured in LocalHTLCFailureReason. In these cases we keep the error string, tolerating some duplication.
These error codes were removed from the specification seven years ago to prevent probing, so we don't need to handle these cases anymore.
De-duplicate use of u16 failure codes by using a macro that will match against each variant's failure_code instead.
There was a problem hiding this comment.
The only comment that I think may not be in this PR is #3601 (comment)
If that one still applies now of course.
| @@ -601,19 +601,18 @@ where | |||
|
|
|||
| pub(super) fn check_incoming_htlc_cltv( | |||
| cur_height: u32, outgoing_cltv_value: u32, cltv_expiry: u32 | |||
| ) -> Result<(), (&'static str, LocalHTLCFailureReason)> { | |||
| ) -> Result<(), LocalHTLCFailureReason> { | |||
There was a problem hiding this comment.
In decode_incoming_update_add_htlc_onion, encode_malformed_error could have its message param dropped perhaps.
There was a problem hiding this comment.
We lose some information from the encode_relay_error calls eg: "Underflow calculating outbound amount or cltv value for blinded forward" just turns into InvalidOnionBlinding.
Tension between internal/api struct shows up there.
There was a problem hiding this comment.
Doesn't that indicate that another enum value is needed, that is mapped to InvalidOnionBlinding on the wire?
There was a problem hiding this comment.
We could add that, but IMO it's not interesting to surface that on the API, and they all map to the same bolt04 code.
So we'd be adding a new enum variant just for the sake of getting rid of a string - not worth the change IMO.
There was a problem hiding this comment.
It isn't completely clear to me why something like Underflow calculating outbound amount or cltv value for blinded forward isn't interesting to surface on the API, while other internal reasons that are also not uniquely mapped to a bolt code are.
This particular string also occurs in the code base multiple times.
But fine to leave as is.
Addressed in 2cc8799 |
| @@ -601,19 +601,18 @@ where | |||
|
|
|||
| pub(super) fn check_incoming_htlc_cltv( | |||
| cur_height: u32, outgoing_cltv_value: u32, cltv_expiry: u32 | |||
| ) -> Result<(), (&'static str, LocalHTLCFailureReason)> { | |||
| ) -> Result<(), LocalHTLCFailureReason> { | |||
There was a problem hiding this comment.
Doesn't that indicate that another enum value is needed, that is mapped to InvalidOnionBlinding on the wire?
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
This PR contains some of the follow ups that didn't make it into #3601:
DisplayforLocalHTLCFailureReasonLocalHTLCFailureReasonin onion error processing, removing the last few places where we were using raw u16 valuesfailure_codeandfrom<u16>to dedup codes