https://bugs.kde.org/show_bug.cgi?id=392440

--- Comment #6 from Bron Gondwana <br...@brong.net> ---
Weell.... what do you know:

2020-08-13T08:28:33-04:00 imap10 (notice) sloti10d1t16/imapnew[2607440]: 
inefficient qresync (2896913 > 2883786) fastmail.fm!user.xxx.Trash
2020-09-12T16:27:44-04:00 imap10 (notice) sloti10d1t16/imapnew[2340095]: 
inefficient qresync (3041269 > 3014441) fastmail.fm!user.xxx.Trash
2020-10-07T05:48:41-04:00 imap10 (notice) sloti10d1t16/imapnew[3996222]: 
inefficient qresync (3240758 > 3102859) fastmail.fm!user.xxx.Trash

That looks suspiciously like it might align with the problem!  This is what
happens when there qresync is against a state from before the last data that
was cleaned up by an expunge.  Interesting.  This suggests there's a bug which
is bumping the deletedmodseq value too high inside the cyrus index, which is
leading to us falling back to the "report all gaps" algorithm, and THAT must be
buggy!

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to