Skip to content

TemporaryChannelFailure without channel update #5822

Closed
@t-bast

Description

@t-bast

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.

Metadata

Metadata

Assignees

Labels

protocolThese issues are protocol level issues that should be discussed on the protocol spec repo

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions