GNU bug report logs - #56332
29.0.50; Large gnus imap groups; articles incorrectly marked as read (old)

Previous Next

Package: emacs;

Reported by: Michael Welsh Duggan <md5i <at> md5i.com>

Date: Fri, 1 Jul 2022 06:48:02 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 56332 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56332 <at> debbugs.gnu.org
Subject: Re: bug#56332: 29.0.50; Large gnus imap groups; articles
 incorrectly marked as read (old)
Date: Sat, 02 Jul 2022 12:40:04 -0400
Michael Welsh Duggan <mwd <at> md5i.com> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Michael Welsh Duggan <mwd <at> 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 <at> md5i.com)




This bug report was last modified 2 years and 324 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.