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: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: 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 17:23:49 +0200
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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




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.