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:
>
>>> Can you do a `M-x debug-on-entry RET nnimap-split-incoming-mail RET' and
>>> then look in the " *nnimap ...*" (note leading space) buffer and see
>>> whether the headers for the articles are there or whether anything looks
>>> obviously messed-up?
>>
>> I think you must have meant a different function?  Because I am not
>> doing any Gnus-side splitting right now (I'm using server-side sieve
>> splitting instead).
>
> Yes, sorry -- I meant nnimap-transform-headers.

Right.  Should have guessed that.  Here's what I have been able to
determine:

1) The problem is non-determinant.  The articles that are marked read
   don't appear as read in every run, and from run to run the list of
   articles that appear as read is not consistent.

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.
   I attach a buffer where I have removed all of the responses except
   for the fetch response sequence numbers along with the message UIDs
   and the FETCH OK responses.  All the sequence numbers are in order
   through 7394 (UID 65348), after which the next response is 7889 (UID
   67026).  That sequence runs until 8048 (UID 67483).  The next set is
   7559 (UID 66026) through 7888 (UID 67024).  This is followed by 7395
   (UID 67024) through 7558 (UID 66024).

   The articles that are marked as "read" are the articles in the
   out-of-sequence sets, those represented by sequence numbers 7395
   through 7888.

Here's the stripped down buffer of responses:

txtL4zVfN4Qmz.txt
Description: Stripped down reponses, in order

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