@@ -905,12 +905,14 @@ where
905
905
/// called [`funding_transaction_generated`] for outbound channels) being closed.
906
906
///
907
907
/// Note that you can be a bit lazier about writing out `ChannelManager` than you can be with
908
- /// [`ChannelMonitor`]. With [`ChannelMonitor`] you MUST write each monitor update out to disk before
909
- /// returning from [`chain::Watch::watch_channel`]/[`update_channel`], with ChannelManagers, writing updates
910
- /// happens out-of-band (and will prevent any other `ChannelManager` operations from occurring during
911
- /// the serialization process). If the deserialized version is out-of-date compared to the
912
- /// [`ChannelMonitor`] passed by reference to [`read`], those channels will be force-closed based on the
913
- /// `ChannelMonitor` state and no funds will be lost (mod on-chain transaction fees).
908
+ /// [`ChannelMonitor`]. With [`ChannelMonitor`] you MUST durably write each
909
+ /// [`ChannelMonitorUpdate`] before returning from
910
+ /// [`chain::Watch::watch_channel`]/[`update_channel`] or before completing async writes. With
911
+ /// ChannelManagers, writing updates happens out-of-band (and will prevent any other
912
+ /// `ChannelManager` operations from occurring during the serialization process). If the
913
+ /// deserialized version is out-of-date compared to the [`ChannelMonitor`] passed by reference to
914
+ /// [`read`], those channels will be force-closed based on the `ChannelMonitor` state and no funds
915
+ /// will be lost (modulo on-chain transaction fees).
914
916
///
915
917
/// Note that the deserializer is only implemented for `(`[`BlockHash`]`, `[`ChannelManager`]`)`, which
916
918
/// tells you the last block hash which was connected. You should get the best block tip before using the manager.
0 commit comments