Improve type safety for message failures

[D4nte]

Follow-up of #596

Edit: Ready for review.

This a step towards a safer handling of failure code and associated data by using a new MessageFailure enum instead of serialising the code and data on call site.

I see several ways to follow-up with this change:

1. Deserialise all possible message failures to MessageFailure, allowing the removal of the HTLCFailReason::Reason variant.
2. Continue to replace call site assignment of code value with instantiation of MessageFailure variables.

One downside of this solution is that I had to clone ChannelUpdate. Let me know if you'd prefer I optimise this before merging.

[jkczyz]

Concept ACK

Would love to see the code move in this direction, too. Thanks for jumping on this!

[TheBlueMatt]

Yep, what Jeff said!

[D4nte]

Need to sort build on old Rust toolchain 😟

[jkczyz]

Need to sort build on old Rust toolchain 😟

Looks like you're running into issues on 1.22.0 with matching enum variants. The syntax is a bit more verbose in this version. You can reproduce the errors using:

cargo +1.22.0 check -p lightning
cargo +1.22.0 test -p lightning

You might find the wire module useful as an example of the syntax if the compiler messages aren't helpful.

[D4nte]

Need to sort build on old Rust toolchain 😟

Looks like you're running into issues on 1.22.0 with matching enum variants. The syntax is a bit more verbose in this version. You can reproduce the errors using:

cargo +1.22.0 check -p lightning
cargo +1.22.0 test -p lightning

You might find the wire module useful as an example of the syntax if the compiler messages aren't helpful.

Yep, thanks, no worries. I was working in Rust already when they did those improvements on the compiler where it is able to infer referencing. It's now ready for review/merge.

[jkczyz]

Follow-up of #596

Edit: Ready for review.

This a step towards a safer handling of failure code and associated data by using a new MessageFailure enum instead of serialising the code and data on call site.

I see several ways to follow-up with this change:

1. Deserialise all possible message failures to MessageFailure, allowing the removal of the HTLCFailReason::Reason variant.
2. Continue to replace call site assignment of code value with instantiation of MessageFailure variables.

I have a bit of a preference to make all these changes in one PR rather than leaving the code in an intermediary state. Or at very least for (2). @TheBlueMatt What do you think?

One downside of this solution is that I had to clone ChannelUpdate. Let me know if you'd prefer I optimise this before merging.

Looks like we were already cloning ChannelUpdate inside peer_disconnected. Or were you referring to somewhere else?

[TheBlueMatt]

Yea, at least personally I really don't mind a larger PR that removes HTLCFailReason::Reason and replaces it with types, obviously with smaller intermediary commits, though.

[D4nte]

Looks like we were already cloning ChannelUpdate inside peer_disconnected. Or were you referring to somewhere else?

Ah yes indeed, all good.

[D4nte]

Yea, at least personally I really don't mind a larger PR that removes HTLCFailReason::Reason and replaces it with types, obviously with smaller intermediary commits, though.

Ok cool, will do that then.

[TheBlueMatt]

@D4nte any plans on updating this?

[D4nte]

@D4nte any plans on updating this?

Hi @TheBlueMatt, I don't see an opportunity to follow-up within the next two months. I'll close for now.