Skip to content

Commit fd67a04

Browse files
committed
Log when a channel is closed on startup due to stale ChannelManager
This is one of the riskiest parts of our API from the perspective of accidental force-closes - if users delay persisting the ChannelManager much at all after a ChannelMonitor we may hit a force-close after restart. The fact that we don't log at all when this happens is criminal.
1 parent bee9a1e commit fd67a04

File tree

1 file changed

+3
-0
lines changed

1 file changed

+3
-0
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4960,6 +4960,9 @@ impl<'a, Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref>
49604960
channel.get_cur_counterparty_commitment_transaction_number() > monitor.get_cur_counterparty_commitment_number() ||
49614961
channel.get_latest_monitor_update_id() < monitor.get_latest_update_id() {
49624962
// But if the channel is behind of the monitor, close the channel:
4963+
log_error!(args.logger, "A ChannelManager is stale compared to the current ChannelMonitor! The channel will be closed.");
4964+
log_error!(args.logger, " The ChannelMonitor for channel {} is at update_id {} but the ChannelManager is at update_id {}.",
4965+
log_bytes!(channel.channel_id()), monitor.get_latest_update_id(), channel.get_latest_monitor_update_id());
49634966
let (_, mut new_failed_htlcs) = channel.force_shutdown(true);
49644967
failed_htlcs.append(&mut new_failed_htlcs);
49654968
monitor.broadcast_latest_holder_commitment_txn(&args.tx_broadcaster, &args.logger);

0 commit comments

Comments
 (0)