f clarify comment some - we cannot prevent duplicate events period, but we CAN only have *either* pre-event state or have the event and not both, which is the issue

Author: TheBlueMatt

lightning/src/chain/channelmonitor.rs

@@ -628,7 +628,8 @@ pub(crate) struct ChannelMonitorImpl<Signer: Sign> {
 	// data processing. This prevents a race in ChainMonitor::update_channel (and presumably user
 	// implementations thereof as well) where we update the in-memory channel object, then before
 	// the persistence finishes (as its all under a read-lock), we return pending events to the
-	// user or to the relevant ChannelManager. This could cause duplicate events.
+	// user or to the relevant ChannelManager. Then, on reload, we'll have the pre-event state
+	// here, but have processed the event in the ChannelManager.
 	// Note that because the `event_lock` in `ChainMonitor` is only taken in
 	// block/transaction-connected events and *not* during block/transaction-disconnected events,
 	// we further MUST NOT generate events during block/transaction-disconnection.