From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8113 invoked from network); 15 Oct 2021 17:43:58 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 15 Oct 2021 17:43:58 -0000 Received: from localhost ([::1]:60158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbRFL-00043v-9z for ml@inbox.vuxu.org; Fri, 15 Oct 2021 13:43:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbRFA-00043K-Oq for info-gnus-english@gnu.org; Fri, 15 Oct 2021 13:43:44 -0400 Received: from ciao.gmane.io ([116.202.254.214]:47530) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbRF8-0005J0-9h for info-gnus-english@gnu.org; Fri, 15 Oct 2021 13:43:44 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mbRF2-0008Y3-FN for info-gnus-english@gnu.org; Fri, 15 Oct 2021 19:43:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: Eric Abrahamsen Subject: Re: Mail source unreachable - continue yes/no? Date: Fri, 15 Oct 2021 10:43:28 -0700 Message-ID: <87sfx2dvzz.fsf@ericabrahamsen.net> References: <22ee8sumb0.fsf@hiptop.liman.net> <87zgrect8z.fsf@gnus.org> <875yu2yyp9.fsf@ericabrahamsen.net> <877deib2q9.fsf@gnus.org> <871r4qyvzm.fsf@ericabrahamsen.net> <8735p6azz2.fsf@gnus.org> <87wnmixg2b.fsf@ericabrahamsen.net> <87wnmi9k27.fsf@gnus.org> <87pmsaxbsj.fsf@ericabrahamsen.net> <874k9l88h2.fsf@gnus.org> <87bl3srye4.fsf@ericabrahamsen.net> <87czo7zw99.fsf@gnus.org> <874k9jqwzb.fsf@ericabrahamsen.net> <87o87q4lih.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cancel-Lock: sha1:kXGXERy2gRZAh/iqSIz0w216yuQ= Received-SPF: pass client-ip=116.202.254.214; envelope-from=gegu-info-gnus-english@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: "info-gnus-english" Lars Ingebrigtsen writes: > Eric Abrahamsen writes: > >> In the meantime I got a backtrace on my stop-the-world nntp connection >> error, which I've posted below. I guess there's nothing mysterious about >> it -- the process dies (I can't tell if it's actually the timeout doing >> it or not), and nntp-accept-process-output/nntp-report ends up raising >> the error, and there's nothing up the line to catch it. Does this look >> surprising or wrong for any reason? >> >> (if nntp--report-1 (progn (if nntp-record-commands (progn >> (nntp-record-command "*** CONNECTION LOST ***"))) (throw > > Network errors are common, so it shouldn't be throwing an error in the > first place. > > But I can't recall ever seeing the `nntp-report' function before, so who > knows what the logic is. :-/ That looks like a... debugging function? The function has existed and raised an error since the "dawn of time" (since CVS days), I guess I'm surprised this hasn't annoyed anyone else. Basically it shadows `nnheader-report', and gives the server a single chance to reconnect in case of failure -- the "nntp-with-open-group" mechanism -- before failing altogether. All that's fine, I wish nnimap had something similar, but raising the error seems wrong. In fact raising the error would be the right thing in the code sketch I posted above! This code is ahead of its time. Anyway, simply removing the call to error should do the trick. That will leave `nnheader-report' as the final form, which returns nil. `nntp-report' is the final form everywhere it's called, so the nil goes up to callers, which will (mostly) interpret that as failure. Eric