Skip to content

Commit 9f8db06

Browse files
committed
Handle BackgroundEvents replaying non-closing monitor updates
`BackgroundEvent` was used to store `ChannelMonitorUpdate`s which result in a channel force-close, avoiding relying on `ChannelMonitor`s having been loaded while `ChannelManager` block-connection methods are called during startup. In the coming commit(s) we'll also generate non-channel-closing `ChannelMonitorUpdate`s during startup, which will need to be replayed prior to any other `ChannelMonitorUpdate`s generated from normal operation. In the next commit we'll handle that by handling `BackgroundEvent`s immediately after locking the `total_consistency_lock`.
1 parent a298912 commit 9f8db06

File tree

1 file changed

+34
-11
lines changed

1 file changed

+34
-11
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 34 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -500,17 +500,20 @@ struct ClaimablePayments {
500500
/// quite some time lag.
501501
enum BackgroundEvent {
502502
/// Handle a ChannelMonitorUpdate which closes the channel. This is only separated from
503-
/// [`Self::MonitorUpdateRegeneratedOnStartup`] as the non-closing variant needs a public key
504-
/// to handle channel resumption, whereas if the channel has been force-closed we do not need
505-
/// the counterparty node_id.
503+
/// [`Self::MonitorUpdateRegeneratedOnStartup`] as the maybe-non-closing variant needs a public
504+
/// key to handle channel resumption, whereas if the channel has been force-closed we do not
505+
/// need the counterparty node_id.
506506
///
507507
/// Note that any such events are lost on shutdown, so in general they must be updates which
508508
/// are regenerated on startup.
509509
ClosingMonitorUpdateRegeneratedOnStartup((OutPoint, ChannelMonitorUpdate)),
510-
/// Handle a ChannelMonitorUpdate which may or may not close the channel. In general this
511-
/// should be used rather than [`Self::ClosingMonitorUpdateRegeneratedOnStartup`], however in
512-
/// cases where the `counterparty_node_id` is not available as the channel has closed from a
513-
/// [`ChannelMonitor`] error the other variant is acceptable.
510+
/// Handle a ChannelMonitorUpdate which may or may not close the channel and may unblock the
511+
/// channel to continue normal operation.
512+
///
513+
/// In general this should be used rather than
514+
/// [`Self::ClosingMonitorUpdateRegeneratedOnStartup`], however in cases where the
515+
/// `counterparty_node_id` is not available as the channel has closed from a [`ChannelMonitor`]
516+
/// error the other variant is acceptable.
514517
///
515518
/// Note that any such events are lost on shutdown, so in general they must be updates which
516519
/// are regenerated on startup.
@@ -3798,10 +3801,30 @@ where
37983801
// monitor updating completing.
37993802
let _ = self.chain_monitor.update_channel(funding_txo, &update);
38003803
},
3801-
BackgroundEvent::MonitorUpdateRegeneratedOnStartup { funding_txo, update, .. } => {
3802-
// The channel has already been closed, so no use bothering to care about the
3803-
// monitor updating completing.
3804-
let _ = self.chain_monitor.update_channel(funding_txo, &update);
3804+
BackgroundEvent::MonitorUpdateRegeneratedOnStartup { counterparty_node_id, funding_txo, update } => {
3805+
let update_res = self.chain_monitor.update_channel(funding_txo, &update);
3806+
3807+
let res = {
3808+
let per_peer_state = self.per_peer_state.read().unwrap();
3809+
if let Some(peer_state_mutex) = per_peer_state.get(&counterparty_node_id) {
3810+
let mut peer_state_lock = peer_state_mutex.lock().unwrap();
3811+
let peer_state = &mut *peer_state_lock;
3812+
match peer_state.channel_by_id.entry(funding_txo.to_channel_id()) {
3813+
hash_map::Entry::Occupied(mut chan) => {
3814+
handle_new_monitor_update!(self, update_res, update.update_id, peer_state_lock, peer_state, per_peer_state, chan)
3815+
},
3816+
hash_map::Entry::Vacant(_) => Ok(()),
3817+
}
3818+
} else { Ok(()) }
3819+
};
3820+
// TODO: If this channel has since closed, we're likely providing a payment
3821+
// preimage update, which we must ensure is durable! We currently don't,
3822+
// however, ensure that.
3823+
if res.is_err() {
3824+
log_error!(self.logger,
3825+
"Failed to provide ChannelMonitorUpdate to closed channel! This likely lost us a payment preimage!");
3826+
}
3827+
let _ = handle_error!(self, res, counterparty_node_id);
38053828
},
38063829
}
38073830
}

0 commit comments

Comments
 (0)