store correct reason of failed forwards in the database

[ScottTre]

Please store the correct reason (channel out of capacity ...) in the forward table and show it in the rpc request

[renepickhardt]

+1

[cdecker]

Unless we are the failing node it is unlikely that we even learn the reason for a failed payment. See the update_fail_htlc message in the spec:

For a timed out or route-failed HTLC:

1. type: 131 (update_fail_htlc)
2. data:
   • [32:channel_id]
   • [8:id]
   • [2:len]
   • [len:reason]

The reason field is an opaque encrypted blob for the benefit of the
original HTLC initiator, as defined in BOLT #4;
however, there's a special malformed failure variant for the case where
the peer couldn't parse it: in this case the current node instead takes action, encrypting
it into a update_fail_htlc for relaying.

So we'd be limited to differentiating malformed HTLC failures (if it's the next hop failing) or an opaque failire if any later node fails. In the case of a local failure we can of course be more verbose and log the failcode.

[trueptolemy]

In the case of a local failure we can of course be more verbose and log the failcode.

Hi, @cdecker! I‘m confused with this:
So, if we should choose to add local failure failcode into DB and add a new rpc command to show these information, or just add a failcode log_entry into LOG with log_unusual/log_broken level?

[cdecker]

I think an optional field in the result of listforwards will do just fine. Storing a numeric failcode also doesn't create a huge overhead in terms of storage, and we can interpret that on the fly when returning the result, but for now let's keep the numeric failcode.

[trueptolemy]

This issue also can be closed(#2524 )