From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.bugs Subject: bug#56332: 29.0.50; Large gnus imap groups; articles incorrectly marked as read (old) Date: Sun, 03 Jul 2022 10:50:46 -0400 Message-ID: <87o7y62qt5.fsf@md5i.com> References: <875ykh9vo1.fsf@md5i.com> <87o7y9xjhd.fsf@gnus.org> <87ilohxiu0.fsf@gnus.org> <87letc7rqn.fsf@md5i.com> <87mtdr3esq.fsf@gnus.org> <87r1334mfm.fsf@md5i.com> <87r133zgfu.fsf@gnus.org> <87ilof4i8x.fsf@md5i.com> <877d4v4gez.fsf@md5i.com> <87tu7ybgx8.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29826"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Michael Welsh Duggan , 56332@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 03 16:51:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o80wJ-0007bh-Uv for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Jul 2022 16:51:12 +0200 Original-Received: from localhost ([::1]:40020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o80wI-0001fS-P1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Jul 2022 10:51:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o80w9-0001fB-UO for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2022 10:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51486) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o80w9-0006SW-M8 for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2022 10:51:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o80w9-0003xz-LF for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2022 10:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Welsh Duggan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Jul 2022 14:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56332 X-GNU-PR-Package: emacs Original-Received: via spool by 56332-submit@debbugs.gnu.org id=B56332.165685985715233 (code B ref 56332); Sun, 03 Jul 2022 14:51:01 +0000 Original-Received: (at 56332) by debbugs.gnu.org; 3 Jul 2022 14:50:57 +0000 Original-Received: from localhost ([127.0.0.1]:45383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o80w4-0003xc-FZ for submit@debbugs.gnu.org; Sun, 03 Jul 2022 10:50:56 -0400 Original-Received: from md5i.com ([75.151.244.229]:36054) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o80w2-0003xO-2n for 56332@debbugs.gnu.org; Sun, 03 Jul 2022 10:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=md5i.com; s=dkim; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1TWcVjWEt4CUd5aLmqd6J05HSI+vtzMcvGXZ634Jv2E=; b=WV1nRuviQkomqlv4VlidimSLvf J4FlYNNUqXz1jxGNSbL7RDaohWyx+eBF/p8gyAab+E2/kC29yXESIkobig7WEZOd2UrFHrkXYM0IS qF5BEPHCQpg6yp6KKXUl4GnlD; Original-Received: from abode ([192.168.177.1] helo=miko) by md5i.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1o80vu-00GpRE-IC; Sun, 03 Jul 2022 10:50:46 -0400 In-Reply-To: <87tu7ybgx8.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 03 Jul 2022 12:59:31 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236005 Archived-At: Lars Ingebrigtsen writes: > Michael Welsh Duggan writes: > >>> I will also note that, though the fetch data responses are not in order, >>> the fetch completion messages are in order. Though I'm not certain they >>> have to be. Here's some data from the Internet, though I can't find >>> anything in the standard that seems to either confirm or refute this >>> data: >>> >>> https://stackoverflow.com/questions/26034086/does-imap-guarantee-that-servers-send-responses-in-order >>> >>> Wouldn't another solution be to sort the results by UID? They are being >>> requested in UID order, after all. >> >> You should probably read this section of the RFC, especially the >> "Note:". >> >> https://datatracker.ietf.org/doc/html/rfc3501#section-5.5 > > Reading that, I'm not sure whether the completion messages are > guaranteed to be in order, either, so I've now changed the code to avoid > streaming altogether. Can you check whether that fixes the problem? > > (If the completion messages are guaranteed to be in order, we could > change it back to using streaming and then just reorder the results, as > you suggest, but I'm not sure it's worth it even if it is guaranteed.) As expected, I cannot cause a failure using this. Though I will note that there is no guarantee that a server will send its untagged fetch responses in any particular order. I will admit that it normally makes very little sense for a server to actually do this in another order, but I can conceive of two reasons that a server might do this, one of which would probably not affect Gnus, but the other of which could: 1) If the messages were not requested in a sorted order, I could see a server generating a sorted order anyway for internal implementation reasons. (Not a problem for Gnus, since it will always request the messages in sorted order.) 2) If messages were being retrieved from some sort of big-data map-reduce store, the messages could conceivable come back in any order due to messages being stored on different nodes with different performance characteristics. The server is not obligated to sort the results before returning them. That said, this fix will work for me for Dovecot and may work on all existent or future IMAP servers, but I don't believe the standard requires that this will be the case. -- Michael Welsh Duggan (md5i@md5i.com)