fix: JMAP fetching and moving#1446
Merged
Merged
Conversation
Email body fetch always failed with "jmap: no cached ID" (backend/jmap/jmap.go) FetchEmailBody relied on p.idToJMAPID being pre-populated by FetchEmails on the same Provider instance. However, the fetcher layer creates a fresh Provider for every call, so the map is always empty when FetchEmailBody runs. The fix adds a resolveUID method that checks the in-memory cache first (fast path when the daemon reuses the same instance), then falls back to resolveUIDByQuery. The fallback issues an Email/query for the folder, reads the JMAP string IDs directly from QueryResponse.IDs, hashes each one with FNV-32a, and returns the match — also warming the cache as a side effect.
floatpanebot
previously requested changes
Jun 5, 2026
Member
floatpanebot
left a comment
floatpanebot
left a comment
There was a problem hiding this comment.
Hi @masukomi! Please fix the following issues with your PR:
- Title: Is too long (48 characters). The PR title must be strictly under 40 characters.
masukomi
changed the title
floatpanebot
previously requested changes
Jun 5, 2026
Member
floatpanebot
left a comment
floatpanebot
left a comment
There was a problem hiding this comment.
Hi @masukomi! Please fix the following issues with your PR:
- Title: Is too long (41 characters). The PR title must be strictly under 40 characters.
andrinoff
changed the title
floatpanebot
dismissed stale reviews from themself
Formatting issues have been resolved. Thank you!
PROBLEM The JMAP backend maps server-assigned string IDs to uint32 UIDs via an in-memory cache (idToJMAPID). Operations like archive, delete, move, and mark read/unread all called lookupJMAPID to translate a UID back to a JMAP ID before making API calls. This cache is only populated when FetchEmails is called on the same Provider instance. The daemon creates one long-lived Provider per account for email mutations, but FetchEmails runs through a separate fetcher layer that creates fresh Provider instances per call. As a result, the mutation provider's cache was always empty, and every archive/delete/move/mark-read attempt failed with jmap: no cached ID for UID <n>. FIX Changed MarkAsRead, MarkAsUnread, DeleteEmail, ArchiveEmail, and MoveEmail in backend/jmap/jmap.go to call resolveUID instead of lookupJMAPID. resolveUID checks the in-memory cache first (fast path, no network), then falls back to resolveUIDByQuery which issues an Email/query for the folder to fetch all IDs, hashes each one to find the match, and warms the cache as a side effect. Subsequent operations on the same provider instance hit the cache.
Contributor
Author
|
added the commit about moving things. Will check in on the CI results later. |
andrinoff
changed the title
Member
|
there are some issues that will need further follow ups. but for now, this is lgtm. To not forget, follow ups:
|
andrinoff
approved these changes
Jun 6, 2026
floatpanebot
pushed a commit
that referenced
this pull request
Jun 6, 2026
## What? in `jmap.go` - added a `resolveUID` function - added a `resolveUIDByQuery` function ## Why? Email body fetch always failed with "jmap: no cached ID" (backend/jmap/jmap.go) FetchEmailBody relied on p.idToJMAPID being pre-populated by FetchEmails on the same Provider instance. However, the fetcher layer creates a fresh Provider for every call, so the map is always empty when FetchEmailBody runs. The fix adds a resolveUID method that checks the in-memory cache first (fast path when the daemon reuses the same instance), then falls back to resolveUIDByQuery. The fallback issues an Email/query for the folder, reads the JMAP string IDs directly from QueryResponse.IDs, hashes each one with FNV-32a, and returns the match — also warming the cache as a side effect. (cherry picked from commit 496a775)
Member
|
Cherry-picked |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
in
jmap.goresolveUIDfunctionresolveUIDByQueryfunctionWhy?
Email body fetch always failed with "jmap: no cached ID" (backend/jmap/jmap.go)
FetchEmailBody relied on p.idToJMAPID being pre-populated by FetchEmails on the same Provider instance. However, the fetcher layer creates a fresh Provider for every call, so the map is always empty when FetchEmailBody runs.
The fix adds a resolveUID method that checks the in-memory cache first (fast path when the daemon reuses the same instance), then falls back to resolveUIDByQuery. The fallback issues an Email/query for the folder, reads the JMAP string IDs directly from QueryResponse.IDs, hashes each one with FNV-32a, and returns the match — also warming the cache as a side effect.