mail: housekeeping left by the placement split (naming, mbox header, UID guard) #410

New Issue

2026-08-12T16:04:16Z

KofTwentyTwo commented

2026-08-12 16:04:16 +00:00

(Migrated from github.com)

Three small items the final review of #394 (PR #405) cleared as non-blocking. Grouped because each is a few lines.

1. sync_folder_messages* return FolderChanges, not messages. sync_folder_messages, sync_folder_messages_with_session and sync_folder_messages_batched all now return an enumeration result — upserts, removals, presence and the next checkpoint. The names date from when they returned a message list. Renaming to sync_folder_changes* is cheap and the return type is explicit at every call site, so the rename is mechanical.

2. export_mbox silently dropped its X-Nuncio-Folder header. The folder is a property of a placement now, not of the message, so export_mbox no longer has one to name. The removal is deliberate and documented in-code, but exported .mbox files quietly lost a header they used to carry. Restoring it means threading the relevant Placement into the signature — worth doing if anything depends on that header, otherwise close this part as intended.

3. Two body-fetch loops lack the UID-less guard the enumeration pass has. Enumeration filters uid >= 1 and counts what it skips. The phase-2a and phase-2b body-fetch loops do not, so a FETCH item arriving without a UID writes a placement with remote_id: "0" — a junk row that no present set can ever contain, so it is written and then deleted on the next pass. RFC 3501 forbids a server from omitting UID in a UID FETCH response, so this needs a non-conforming server to trigger. Mirror the enumeration skip and count it.

Three small items the final review of #394 (PR #405) cleared as non-blocking. Grouped because each is a few lines. **1. `sync_folder_messages*` return `FolderChanges`, not messages.** `sync_folder_messages`, `sync_folder_messages_with_session` and `sync_folder_messages_batched` all now return an enumeration result — upserts, removals, presence and the next checkpoint. The names date from when they returned a message list. Renaming to `sync_folder_changes*` is cheap and the return type is explicit at every call site, so the rename is mechanical. **2. `export_mbox` silently dropped its `X-Nuncio-Folder` header.** The folder is a property of a placement now, not of the message, so `export_mbox` no longer has one to name. The removal is deliberate and documented in-code, but exported `.mbox` files quietly lost a header they used to carry. Restoring it means threading the relevant `Placement` into the signature — worth doing if anything depends on that header, otherwise close this part as intended. **3. Two body-fetch loops lack the UID-less guard the enumeration pass has.** Enumeration filters `uid >= 1` and counts what it skips. The phase-2a and phase-2b body-fetch loops do not, so a FETCH item arriving without a UID writes a placement with `remote_id: "0"` — a junk row that no `present` set can ever contain, so it is written and then deleted on the next pass. RFC 3501 forbids a server from omitting UID in a `UID FETCH` response, so this needs a non-conforming server to trigger. Mirror the enumeration skip and count it.

KofTwentyTwo commented

2026-08-14 22:57:28 +00:00

(Migrated from github.com)

Done in #413 (fdbd1a5). sync_folder_messages* renamed to sync_folder_changes* to match what they return; the UID-less guard added to both body-fetch loops, feeding the existing skipped counter.

export_mbox's X-Nuncio-Folder header is permanently omitted, not pending: a message can hold several placements, so a single header would name one arbitrarily and MBOX cannot express the set. Restoring it would need a multi-header or per-placement export design, not a signature change. The in-code comment now says so.

Done in #413 (`fdbd1a5`). `sync_folder_messages*` renamed to `sync_folder_changes*` to match what they return; the UID-less guard added to both body-fetch loops, feeding the existing `skipped` counter. `export_mbox`'s `X-Nuncio-Folder` header is **permanently omitted**, not pending: a message can hold several placements, so a single header would name one arbitrarily and MBOX cannot express the set. Restoring it would need a multi-header or per-placement export design, not a signature change. The in-code comment now says so.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/nuncio#410