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.