Description
Opening up this issue to track a few comments in #3700 and #3744.
1. Add additional metadata to error variants
There are some LocalHTLCFailureReason variants that have metadata that may be interesting for a dashboard, for example HTLCMaximum provides some insight into the amount of liquidity that is available (vs what was needed by the HTLC).
One side effect of not having this data tracked with the failure is that we can't use the enum's display string without losing some information that's probably quite useful to know in our logs.
2. Surface hold time for attributable failures
With attributable failures implemented, we now know how long our downstream peer held the HTLC for. This can be surfaced in the Downstream variant of HTLCHandlingFailureReason.
3. Imperfect Mapping of bad onion failures
In decode_incoming_update_add_htlc_onion and OnionDecodeErr::Malformed there are still some error strings that are more specific than LocalHTLCFailureReason. This happens because we're using the same enum internally and on the API - these errors are more detailed than we care to surface on the API.
As a result, getting rid of their accompanying strings would also result in some information loss in our logs.
If we wanted this to be more internally consistent, I think that the best way to do it would be to add new enums for the different InvalidOnionBlinding and InvalidOnion cases that we see in detail in the codebase, and then add then as fields to the corresponding LocalHTLCFailureReason variant as a field.