Closed
Description
I'm making some e2e tests with cln 22.11, and noticed that we fail to parse some of your errors.
The reason is that cln sometimes returns a TemporaryChannelFailure
without an enclosed channel_update
, while we expect one. For example, I'm receiving this error (after decryption):
86abd17911a15dcd41053173c1cbaf9d173bb7199e170c518127ff97c2cbbdb8 (mac)
0004 (failure message length)
1007 0000 (temporary_channel_failure with channel_update length = 0)
00fc (padding length)
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (padding)
The spec says:
Please note that the channel_update field is mandatory in messages whose failure_code includes the UPDATE flag.
We've had this issue in the past with lnd, but they eventually fixed it.
This is creating real issues for payment reliability, because this prevents retries with smaller amounts since we don't realize that this is a temporary failure (which most likely indicates a liquidity issue).
We should decide whether we want to relax the spec and allow not enclosing a channel_update
in this case, or if this is a bug that must be fixed when creating the error.