From f10b91fcedab7bc8c8fc344eeeb6337e4600aac9 Mon Sep 17 00:00:00 2001 From: Richard Holzeis Date: Thu, 24 Aug 2023 15:04:17 +0200 Subject: [PATCH] fix: Drop pending finalize messages on disconnected peer If the peer disconnects before the pending finalize message could have been processed, the recovery logic is in conflict with the hanging message. Both parties return to the offered state and try to recover from there, now the pending `Finalize` message is out of place. We had a similar issue with a pending `Confirm` message. I presume this issue got introduced after the protocol was extended for the `Revoke` message. --- dlc-messages/src/message_handler.rs | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/dlc-messages/src/message_handler.rs b/dlc-messages/src/message_handler.rs index a35afc93..d0e826e7 100644 --- a/dlc-messages/src/message_handler.rs +++ b/dlc-messages/src/message_handler.rs @@ -117,6 +117,16 @@ impl MessageHandler { ); false } + Message::SubChannel(SubChannelMessage::Finalize(message)) + if node_id == disconnected_node_id => + { + log::warn!( + "Dropping SubChannelFinalize message for channel {:?} \ + after peer {node_id} disconnected", + message.channel_id + ); + false + } Message::SubChannel(SubChannelMessage::CloseConfirm(message)) if node_id == disconnected_node_id => { @@ -127,6 +137,16 @@ impl MessageHandler { ); false } + Message::SubChannel(SubChannelMessage::CloseFinalize(message)) + if node_id == disconnected_node_id => + { + log::warn!( + "Dropping SubChannelCloseFinalize message for channel {:?} \ + after peer {node_id} disconnected", + message.channel_id + ); + false + } // Keep any other message _ => true, }