Try to recover from UIDNEXT mismatch
Review Request #101142 - Created April 16, 2011 and submitted
In case the IMAP resource ends up with an mismatch in current and last seen UIDNEXT values, it tries to recover from that with a full re-download. With online IMAP that's not too bad, but for the offline case this can be a huge problem. So, I tried to come up with a less drastic way, but please verify my assumptions, I cannot test this scenario here, my IMAP server behaves too well. So, my assumption is that this case can happen because of an equal amount of emails being added and deleted while we were not looking. Then the message count check passes (we still have the same amount locally and remotely), but the UIDNEXT check fails. If this is correct, and given UIDs are strictly ascending, the maximum amount of changed messages is (newUidnext - oldUidnext). So, instead of downloading everything, we now only download that many messages, since download is done by sequence number, we are guaranteed to get the newest ones and thus we cover all new messages. Deletion of the old ones is done by the subsequent flag fetch step, just as in the normal case. Does this make sense? Thiago's problem shown in bug 259151 is slightly different, there we do the same modification locally and remotely but fail to obtain the new UID due to the server not supporting UIDPLUS and the message-id being non-unique. However, this should work with the above approach as well.
None, unfortunately, I cannot trigger this code path here since I have no access to a non-UIDPLUS server.