The server dropped the connection mid-poll once ("Broken pipe"); the
scheduler kept using the dead connection, so the remaining ~400 mails
of the batch each failed and were still marked as processed — i.e.
silently never evaluated again.
- Fetch retries once after reconnecting on connection-level errors
(IMAP4.abort, OSError incl. timeouts/SSL). If the reconnect fails,
the poll stops with a single warning, keeps the progress so far and
leaves the remaining mails unmarked for the next poll.
- A failed action followed by a dead connection triggers a reconnect;
that mail is not marked as processed, so it is retried next poll.
- IMAPClient.reconnect() / is_alive() helpers.
Checked with a simulated server: single drop (all mails processed, no
errors), permanent outage (one warning, rest unmarked), drop during a
move (mail left unmarked for retry).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>