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


View this message in rfc822 format

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

-- 
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.