Try to recover from UIDNEXT mismatch

Review Request #101142 - Created April 16, 2011 and submitted

Volker Krause
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.
Till Adam
I think the reasoning is sound, but I was wondering about the qMax(11l, ... What's the idea behind that magic number?
  1. I read that as 1ll (one + L +L) and that would be (long long) 1, or?
  2. Yes, it's 1LL not 111, in order to disambiguate qMax(int, long long). It's just paranoia to protect against a invalid (negative) start index in case of totally bogus input. 
Torgny Nyblom
Looks good to me, just one question below.
resources/imap/retrieveitemstask.cpp (Diff revision 1)
Why not use startIndex here?
Kevin Ottens
And what about a unit test to exercise this behavior?
  1. I knew you would ask, at least I made most of the unit tests work again already :)
  2. Hehe, well that's a good start. ;-)
    More seriously, I think that's even more important than usual for your latest two patches because you have no access to a server not supporting UIDPLUS and you'd be able to simulate that at least partly.
Commit Hook
This review has been submitted with commit 6adf3ac1bf26662d9e81fa43aced445ecb659d4f by Volker Krause.