Re: bug#62044: 30.0.50; ERC 5.5: Auto-reconnect is broken

[J.P.]

xoddf2 <woddfellow2@gmail.com> writes:

> J.P. writes:
>
>> [...]
>>
>> I've improved upon this further (v3 attached) by adding a housekeeping
>> task to monitor the initial server process from creation. Such a move
>> may be regrettable because it adds yet more complexity to the already
>> dizzying auto-reconnect landscape. However, I couldn't find a suitable
>> way to cover common process errors that aren't presented to the sentinel
>> but still need to engage the reconnect logic.
>>
>> If this leads to a futile game of whack-a-mole, we'll obviously need to
>> try a different approach. But if we do more-or-less build on what I've
>> got so far, we'll definitely need to ensure it agrees with 27 and 28
>> before spending serious energy on refinement and tests.
>>
>> Thanks.
>
> Version 3 of the patch works, both with an otherwise unconfigured ERC
> and with a full configuration connecting to my bouncer.
>
> I used this setting in both cases:
> (setq erc-server-reconnect-function 'erc-server-delayed-check-reconnect)

Really appreciate your trying this out.

> The first 2 versions did not work at all.

Right, and the last one still fails under various (hopefully less
common) conditions, such as an outbound firewall dropping rather than
rejecting packets. But the main problem (IMO) is unneeded complexity,
and that stems from a fundamental design flaw in ERC: initializing new
buffers and mode/module resources before creating connections, hence
resorting to a probe to check for connectivity, which is roundabout and
error prone. But until people become willing to accept the many breaking
changes that a redesign would spell, I'm afraid we're stuck relying on
these unfriendly contortions.

As for next steps, I've polished up this patch some and have marked it
for preliminary inclusion in what will become ERC 5.6.

Thanks again.

0000-v3-v4.diff
Description: Text Data

0001-5.6-Add-probing-erc-server-reconnect-function-varian.patch
Description: Text Data