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

Previous Next

Full log

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

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

Previous Next

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