Refactor validated_expected_channel()
and check_destination_channel_state()
#4056
Labels
A: low-priority
Admin: low priority / non urgent issue, expect longer wait time for PR reviews
Summary
When building channel handshake messages,
validated_expected_channel()
is used to retrieve the specified channel end from the destination and check if it matches the state that is required for the handshake message to be successful.validated_expected_channel()
and the sub-methodcheck_destination_channel_state()
could use some improvement given that:validated_expected_channel()
currently returns aChannelEnd
object that is never used, it's not clear why this is needed.Both the
OpenAck
andOpenConfirm
messages expect the receiving channel end's highest state to beTRYOPEN
. It would be helpful to clarify in the comments why this is needed. Is it due to crossing hellos?check_destination_channel_state()
could also use refactoring or could be merged intovalidated_expected_channel()
Proposal
Refactor
validated_expected_channel()
andcheck_destination_channel_state()
and add comments to enhance clarity. Since this involves thetx
CLIs, it can potentially be done together with the work to support multihop connections on those same CLIs (#3940).For Admin Use
The text was updated successfully, but these errors were encountered: