Add exact UID-set fetch API - #121
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 271d6e236d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fetchByByteStringSet _ [] _ = return [] | ||
| fetchByByteStringSet conn uids command = | ||
| fetchCommandBS conn | ||
| ("UID FETCH "++intercalate "," (map show uids)++" "++command) proc |
There was a problem hiding this comment.
When this helper receives a large SEARCH result, it serializes every UID into one unbounded IMAP command line. IMAP servers commonly impose command-line length limits, so sufficiently large but valid UID sets will be rejected with BAD instead of being fetched—particularly in the bulk search-result use case this API targets. Partition the UIDs into bounded sequence-set commands and concatenate their responses, or expose and document an explicit size limit.
Useful? React with 👍 / 👎.
|
@qnikst this one is also good to go I think :) |
|
I have approved, but I find codex comment useful. If there is a need and it’s not hard it would be nice to implement that, otherwise it opens a possibility for DDoS attack or unrecoverable failure, if server rejects messages that are too big but it’s ok to have that in a separate pr |
|
And I will merge this one, I don’t think we will break the internet by adding clear et solution later ;) |
|
Merged, thanks for your work! |
2 participants
Summary
fetchByByteStringSetfor fetching arbitrary data items from an exact list of UIDs101,205,999, rather than widening them to a rangeUID FETCHcommandByteStringvalues and response-UID mapping used byfetchByByteStringRWhy
IMAP searches commonly return sparse UIDs. The existing
fetchByByteStringRAPI accepts only a contiguous range, so using the first and last search result can fetch many unrelated messages between them. Calling the single-UID API in a loop avoids over-fetching but adds one network round trip per message.This helper allows callers to batch metadata reads such as
BODYSTRUCTUREfor exactly the search results they need.Validation
doCheckbuild with GHC 9.10.3imap-parsers: 50 cases, 0 errors, 0 failures