v0.2.25

src/undo_send.rs

@@ -1,18 +1,5 @@
-//! In-memory staging for "Undo Send".
-//!
-//! When `undo_send_window_secs > 0`, a fully built outgoing message is held
-//! in memory for that many seconds before it is actually dispatched to SMTP,
-//! so the sender can cancel it. Nothing here is persisted: a server restart
-//! during the window loses any message still staged, the same way a message
-//! already queued by any mail server can be lost if the process is killed
-//! mid-flight. The window is meant to be short (seconds, not minutes) for
-//! exactly this reason.
-//!
-//! State transitions are `Pending -> Cancelled` (a user clicks "Undo") or
-//! `Pending -> Dispatching -> Sent | Failed` (the window elapses). Both the
-//! cancel handler and the delayed dispatch task race to leave `Pending`, but
-//! only one of them can win because the transition happens under a single
-//! mutex: whichever reaches it first decides the outcome.
+//! In-memory staging for "Undo Send" (not persisted). A send is either
+//! cancelled or dispatched; the transition happens under one mutex.
 
 use std::collections::HashMap;
 use std::sync::Mutex;
@@ -94,10 +81,7 @@ impl UndoSendRegistry {
         }
     }
 
-    /// Called by the delayed dispatch task once its wait is over, right
-    /// before it would contact SMTP. Returns `true` if this call is the one
-    /// that claimed the send (i.e. it was not cancelled in the meantime);
-    /// the caller must then actually dispatch and record the result.
+    /// Claims the send for dispatch; `false` if it was cancelled.
     pub fn begin_dispatch(&self, id: &str) -> bool {
         let mut entries = self.entries.lock().expect("undo-send registry lock");
         match entries.get_mut(id) {