GNU bug report logs - #62044
30.0.50; ERC 5.5: Auto-reconnect is broken

Previous Next

Package: emacs;

Reported by: xoddf2 <woddfellow2 <at> gmail.com>

Date: Wed, 8 Mar 2023 06:14:01 UTC

Severity: normal

Found in version 30.0.50

Full log


View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: 62044 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: bug#62044: 30.0.50; ERC 5.5: Auto-reconnect is broken
Date: Wed, 09 Apr 2025 17:28:45 -0700
[Message part 1 (text/plain, inline)]
"J.P." <jp <at> neverwas.me> writes:

> At the end of the day, I still question the soundness of resorting to a
> protocol exchange to prove that the underlying transport is functioning
> properly. However, if no one complains in the next week or two, I'll
> close this with the release of 5.6.1.

This "delayed check" method has reportedly been failing for some users.
It apparently "hangs" at some point while redialing and displays a
negative countdown in the mode line segment. If my suspicions are
correct, this is somewhat of a known issue related to the sending of a
"stateless" pre-connection-registration message, namely a PING, which is
pretty nonstandard for clients.

One possible solution that springs to mind involves reusing the last
session's local state to perform the initial "$hello" of the so-called
"connection registration" sequence. It would interpret any response as
indicative of a healthy connection and stash it in order to first
initialize the session properly before processing the stashed response
manually at the juncture where its request (the "$hello" thing) would
normally be emitted. This solution is appealing in that it would
preserve the program's basic design and contracts. However, its fatal
flaw would be performing connection registration in the old session's
buffer. Doing this hampers modularity by making it difficult if not
impossible for modules to meaningfully influence the process. In any
case, the second of the attached patches (the one labeled "POC") demos
this approach.

For now, I think our best option is to forgo emitting _any_ pre-
registration protocol and to instead accept the "open\n" event from the
process sentinel as sufficient evidence our messages are getting
through. Of course, not seeing a single response means this reconnect
method may still fail with some proxies, which is something I guess
we'll just have to live with. Anyway, the first of the attached patches
(the one labeled "5.6.1") hopefully does this in a competent way. Those
affected by this bug are encouraged to give it a try.

In the end, the fact remains that anything short of fully integrating
the reconnect logic into session setup and the connection-registration
dialog will always be a hack and prone to failure. Unfortunately, such a
comprehensive overhaul would mean reworking the way ERC initializes
sessions and would break way too much user code. But it's something
perhaps worth revisiting on a major version release.

Thanks.

[0001-5.6.1-Don-t-round-trip-auto-reconnect-probe-in-ERC.patch (text/x-patch, attachment)]
[0001-POC-Send-full-erc-login-as-reconnect-probe.patch (text/x-patch, attachment)]

This bug report was last modified 65 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.