- /// Used to indicate no further channel monitor updates will be allowed (likely a disk failure
- /// or a remote copy of this [`ChannelMonitor`] is no longer reachable and thus not updatable).
- ///
- /// When this is returned, [`ChannelManager`] will force-close the channel but *not* broadcast
- /// our current commitment transaction. This avoids a dangerous case where a local disk failure
- /// (e.g. the Linux-default remounting of the disk as read-only) causes [`PermanentFailure`]s
- /// for all monitor updates. If we were to broadcast our latest commitment transaction and then
- /// restart, we could end up reading a previous [`ChannelMonitor`] and [`ChannelManager`],
- /// revoking our now-broadcasted state before seeing it confirm and losing all our funds.
- ///
- /// Note that this is somewhat of a tradeoff - if the disk is really gone and we may have lost
- /// the data permanently, we really should broadcast immediately. If the data can be recovered
- /// with manual intervention, we'd rather close the channel, rejecting future updates to it,
- /// and broadcast the latest state only if we have HTLCs to claim which are timing out (which
- /// we do as long as blocks are connected).
- ///
- /// In order to broadcast the latest local commitment transaction, you'll need to call
- /// [`ChannelMonitor::get_latest_holder_commitment_txn`] and broadcast the resulting
- /// transactions once you've safely ensured no further channel updates can be generated by your
- /// [`ChannelManager`].
- ///
- /// Note that at least one final [`ChannelMonitorUpdate`] may still be provided, which must
- /// still be processed by a running [`ChannelMonitor`]. This final update will mark the
- /// [`ChannelMonitor`] as finalized, ensuring no further updates (e.g. revocation of the latest
- /// commitment transaction) are allowed.
- ///
- /// Note that even if you return a [`PermanentFailure`] due to unavailability of secondary
- /// [`ChannelMonitor`] copies, you should still make an attempt to store the update where
- /// possible to ensure you can claim HTLC outputs on the latest commitment transaction
- /// broadcasted later.
- ///
- /// In case of distributed watchtowers deployment, the new version must be written to disk, as
- /// state may have been stored but rejected due to a block forcing a commitment broadcast. This
- /// storage is used to claim outputs of rejected state confirmed onchain by another watchtower,
- /// lagging behind on block processing.
- ///
- /// [`PermanentFailure`]: ChannelMonitorUpdateStatus::PermanentFailure
- /// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
- PermanentFailure,
+ /// Indicates that an update has failed and will not complete at any point in the future.
+ ///
+ /// Currently returning this variant will cause LDK to immediately panic to encourage immediate
+ /// shutdown. In the future this may be updated to disconnect peers and refuse to continue
+ /// normal operation without a panic.
+ ///
+ /// Applications which wish to perform an orderly shutdown after failure should consider
+ /// returning [`InProgress`] instead and simply shut down without ever marking the update
+ /// complete.
+ ///
+ /// [`InProgress`]: ChannelMonitorUpdateStatus::InProgress
+ UnrecoverableError,