Imap.fetch_new_messages() processes full downloads and partial downloads with at most two calls to fetch_many_msgs(). If the Inbox contains X small messages followed by Y large messages followed by Z small messages, Delta Chat first downloads a batch of X+Z messages, and then a batch of Y messages.
This bug was discovered by @Simon-Laux while testing reactions PR #3644 and can be reproduced with online test as follows:
- Bob enables download limit and goes offline.
- Alice sends a large message to Bob and reacts to this message with a thumbs-up.
- Bob goes online
- Bob first processes a reaction message and throws it away because there is no corresponding message, then processes a partially downloaded message.
- As a result, Bob does not see a reaction
Delta Chat assumes in-order processing in a lot of places, for example group management, ephemeral timers and quotes are affected by this even if there are some workarounds. If messages are already seen on the IMAP server, partially downloaded messages will be added to the end of the chat instead of before the batch of Z messages.
The solution is to do fetching in as many batches as needed, e.g. in this case first download X messages via first FETCH, then Y messages via header FETCH and then remaining Z messages with a full FETCH again. Saving the traffic in this case is not worth the bugs produced by out-of-order receive_imf processing.
Imap.fetch_new_messages()processes full downloads and partial downloads with at most two calls tofetch_many_msgs(). If the Inbox contains X small messages followed by Y large messages followed by Z small messages, Delta Chat first downloads a batch of X+Z messages, and then a batch of Y messages.This bug was discovered by @Simon-Laux while testing reactions PR #3644 and can be reproduced with online test as follows:
Delta Chat assumes in-order processing in a lot of places, for example group management, ephemeral timers and quotes are affected by this even if there are some workarounds. If messages are already seen on the IMAP server, partially downloaded messages will be added to the end of the chat instead of before the batch of Z messages.
The solution is to do fetching in as many batches as needed, e.g. in this case first download X messages via first FETCH, then Y messages via header FETCH and then remaining Z messages with a full FETCH again. Saving the traffic in this case is not worth the bugs produced by out-of-order
receive_imfprocessing.