- Shipped
- August 14, 2026 at 2:24 AM UTC
- Author
- Kamo
- Commit
- d70fbde
The rows behind a message list are already in Postgres — the metadata index holds sender, subject, date, size, attachment and flags for every message it has seen. Reading a page from there is one query; reading it from IMAP is a SELECT plus a fifty-envelope FETCH and makes the server build the mailbox index to answer. What stopped anyone using it was not speed but trust. The index is filled by a push indexer that only runs while somebody has the mailbox open, so it is allowed to be arbitrarily stale, and nothing distinguished a current folder from a stale one. One STATUS distinguishes them. It is the cheapest question IMAP answers — no SELECT, no message data — and it returns the folder's message count and its next UID. The index is used only when both match what it holds: the count catches anything added or removed, and maxUid + 1 == UIDNEXT catches the case a count cannot see, where as many arrived as were deleted. UIDNEXT only moves forward, so an append the index missed leaves it stranded above the highest UID the index knows. Every other outcome falls back to IMAP: a missing folder, a server that decoders STATUS, an empty index, a database error. The worst available result is the behaviour that existed before this. A folder that fails the test heals itself when the next message arrives and is indexed. Off by default behind **************** because the reply marker depends on search_index.is_answered, which does not exist until KamoInitializer has run. Turning it on is then a deliberate act rather than a side effect of a deploy. The agreement predicate is where being wrong shows someone the wrong mail, so it is pure, package-private and tested from that direction — every case asks whether it can use the index when it must not.