Skip to content

Commit f4c2f80

Browse files
committed
Fail channel if we can't sign a new commitment tx during HTLC claim
Previously, we could fail to generate a new commitment transaction but it simply indicated we had gone to doule-claim an HTLC. Now that double-claims are returned instead as Ok(None), we should handle the error case and fail the channel, as the only way to hit the error case is if key derivation failed or the user refused to sign the new commitment transaction.
1 parent 735456e commit f4c2f80

File tree

1 file changed

+6
-9
lines changed

1 file changed

+6
-9
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 6 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -2709,15 +2709,12 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana
27092709
return Ok(())
27102710
},
27112711
Err(e) => {
2712-
// TODO: Do something with e?
2713-
// This should only occur if we are claiming an HTLC at the same time as the
2714-
// HTLC is being failed (eg because a block is being connected and this caused
2715-
// an HTLC to time out). This should, of course, only occur if the user is the
2716-
// one doing the claiming (as it being a part of a peer claim would imply we're
2717-
// about to lose funds) and only if the lock in claim_funds was dropped as a
2718-
// previous HTLC was failed (thus not for an MPP payment).
2719-
debug_assert!(false, "This shouldn't be reachable except in absurdly rare cases between monitor updates and HTLC timeouts: {:?}", e);
2720-
return Err(None)
2712+
let counterparty_node_id = chan.get().get_counterparty_node_id();
2713+
let (drop, res) = convert_chan_err!(self, e, channel_state.short_to_id, chan.get_mut(), &chan_id);
2714+
if drop {
2715+
chan.remove_entry();
2716+
}
2717+
return Err(Some((counterparty_node_id, res)));
27212718
},
27222719
}
27232720
} else { unreachable!(); }

0 commit comments

Comments
 (0)