bug#56332: 29.0.50; Large gnus imap groups; articles incorrectly marked as read (old)

[Michael Welsh Duggan]

Michael Welsh Duggan <mwd@md5i.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Michael Welsh Duggan <mwd@md5i.com> writes:
>>
>>> 2) When the problem happens, it seems to happen because the order of the
>>>    fetch responses do not appear in the order of the fetches themselves.
>>
>> Oh, that's interesting.  IMAP is a streaming protocol, so if you send
>> two commands after one another, you should first get the responses from
>> the first, and then from the last.  It sounds like UID FETCH doesn't
>> respect that?
>>
>> In which case the simple solution would be to wait until the first
>> command has ended before issuing a new one, but that would make things a
>> bit slower (depending on the latency of the connection).
>>
>> Hm...  OK, I've tried this myself now, and I can definitely see
>> something odd here.  I don't see shuffled headers, but I see
>>
>> OUTPUT FROM FIRST
>> OUTPUT FROM SECOND
>> 26166 OK Fetch completed (0.002 + 0.000 + 0.001 secs).
>> 26167 OK Fetch completed (0.002 + 0.000 + 0.001 secs).
>> 
>> So that seems to support this -- UID FETCH is not really streamable (at
>> least not with this IMAP server).  I'm using Dovecot -- are you using
>> the same?
>
> I am using Dovecot.  I am betting that the only reason I am seeing
> shuffled headers is due to the larger group, and maybe due to the
> sparsity of the UIDs.  More fetches grant more opportunity for random
> re-ordering.
>
> I will also note that, though the fetch data responses are not in order,
> the fetch completion messages are in order.  Though I'm not certain they
> have to be.  Here's some data from the Internet, though I can't find
> anything in the standard that seems to either confirm or refute this
> data:
>
> https://stackoverflow.com/questions/26034086/does-imap-guarantee-that-servers-send-responses-in-order
>
> Wouldn't another solution be to sort the results by UID?  They are being
> requested in UID order, after all.

You should probably read this section of the RFC, especially the
"Note:".

https://datatracker.ietf.org/doc/html/rfc3501#section-5.5

-- 
Michael Welsh Duggan
(md5i@md5i.com)