- /// have been successfully applied, ChannelManager::channel_monitor_updated can be used to
- /// restore the channel to an operational state.
- ///
- /// Note that a given ChannelManager will *never* re-generate a given ChannelMonitorUpdate. If
- /// you return a TemporaryFailure you must ensure that it is written to disk safely before
- /// writing out the latest ChannelManager state.
- ///
- /// Even when a channel has been "frozen" updates to the ChannelMonitor can continue to occur
- /// (eg if an inbound HTLC which we forwarded was claimed upstream resulting in us attempting
- /// to claim it on this channel) and those updates must be applied wherever they can be. At
- /// least one such updated ChannelMonitor must be persisted otherwise PermanentFailure should
- /// be returned to get things on-chain ASAP using only the in-memory copy. Obviously updates to
- /// the channel which would invalidate previous ChannelMonitors are not made when a channel has
- /// been "frozen".
- ///
- /// Note that even if updates made after TemporaryFailure succeed you must still call
- /// channel_monitor_updated to ensure you have the latest monitor and re-enable normal channel
- /// operation.
- ///
- /// Note that the update being processed here will not be replayed for you when you call
- /// ChannelManager::channel_monitor_updated, so you must store the update itself along
- /// with the persisted ChannelMonitor on your own local disk prior to returning a
- /// TemporaryFailure. You may, of course, employ a journaling approach, storing only the
- /// ChannelMonitorUpdate on disk without updating the monitor itself, replaying the journal at
- /// reload-time.
+ /// have been successfully applied, a [`MonitorEvent::Completed`] can be used to restore the
+ /// channel to an operational state.
+ ///
+ /// Note that a given [`ChannelManager`] will *never* re-generate a [`ChannelMonitorUpdate`].
+ /// If you return this error you must ensure that it is written to disk safely before writing
+ /// the latest [`ChannelManager`] state, or you should return [`PermanentFailure`] instead.
+ ///
+ /// Even when a channel has been "frozen", updates to the [`ChannelMonitor`] can continue to
+ /// occur (e.g. if an inbound HTLC which we forwarded was claimed upstream, resulting in us
+ /// attempting to claim it on this channel) and those updates must still be persisted.
+ ///
+ /// No updates to the channel will be made which could invalidate other [`ChannelMonitor`]s
+ /// until a [`MonitorEvent::Completed`] is provided, even if you return no error on a later
+ /// monitor update for the same channel.