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

[Michael Welsh Duggan]

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.

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