JMAP parse_email_get_response hardcodes folder_id='inbox' (mislabels non-inbox mailboxes) #339

New Issue

2026-07-31T18:52:15Z

KofTwentyTwo commented

2026-07-31 18:52:15 +00:00

(Migrated from github.com)

Pre-existing quirk surfaced during WS-B1 (#281) review: JMAP parse_email_get_response sets folder_id='inbox' for parsed emails while sync_folders reports the real mailbox id. NOT a surrogate-id collision (the JMAP object id in remote_id is account-globally-unique per RFC 8621, so the identity tuple stays distinct, and the outbox mutates by object id) — but messages from non-inbox JMAP mailboxes are mislabeled by folder in the store, which will matter for folder-scoped views/search. Fix: carry the real mailbox id through parse_email_get_response. Source: #337 review Minor #3.

KofTwentyTwo commented

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

(Migrated from github.com)

Partly overtaken by #414, but not closable as written — leaving open deliberately.

While implementing JMAP Email/changes, the hardcoded folder_id = "inbox" turned out to be load-bearing rather than cosmetic. Removals key on (account_id, folder_id, uid_validity, remote_id), and the daemon syncs folders by JMAP mailbox id (e.g. mb-inbox), so a removal could never match a placement stored under "inbox" — every JMAP removal would have been silently inert, defeating the ghost-message fix entirely.

#414 therefore fixes the production path: placements are now labelled with the mailbox actually being synced. Two existing assertions that encoded the old mislabelling were updated.

What remains, and why this stays open: the public parse_email_get_response helper keeps its fixed-folder signature, which is the literal subject of this issue. Closing it would overstate what changed.

Partly overtaken by #414, but **not closable as written** — leaving open deliberately. While implementing JMAP `Email/changes`, the hardcoded `folder_id = "inbox"` turned out to be load-bearing rather than cosmetic. Removals key on `(account_id, folder_id, uid_validity, remote_id)`, and the daemon syncs folders by JMAP mailbox id (e.g. `mb-inbox`), so a removal could **never** match a placement stored under `"inbox"` — every JMAP removal would have been silently inert, defeating the ghost-message fix entirely. #414 therefore fixes the **production path**: placements are now labelled with the mailbox actually being synced. Two existing assertions that encoded the old mislabelling were updated. What remains, and why this stays open: the public `parse_email_get_response` helper keeps its fixed-folder signature, which is the literal subject of this issue. Closing it would overstate what changed.

KofTwentyTwo commented

2026-08-15 00:54:36 +00:00

(Migrated from github.com)

Fixed in #418 (4bbb23b), merged to dev. The public parse_email_get_response now takes the folder it is parsing for; the private parse_email_get_response_in_folder workaround is gone and all four call sites pass a real JMAP mailbox id. The production mislabelling was already corrected in #414 — that mattered because removals key on folder, so the hardcoded "inbox" made every JMAP removal inert.

Fixed in #418 (`4bbb23b`), merged to `dev`. The public `parse_email_get_response` now takes the folder it is parsing for; the private `parse_email_get_response_in_folder` workaround is gone and all four call sites pass a real JMAP mailbox id. The production mislabelling was already corrected in #414 — that mattered because removals key on folder, so the hardcoded `"inbox"` made every JMAP removal inert.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/nuncio#339