Fix a keepalive ping timeout killing the bot for good
Bot overrode disconnect() to tear down the workers and raise SystemExit,
but slixmpp calls disconnect() itself as the first half of a reconnect:
xep_0199's keepalive does self.xmpp.reconnect(0.0, "Ping timeout after
%ds") on a missed ping, and reconnect() calls disconnect(0.0, reason).
Against the override's signature (reconnect=False, wait=None, ...) that
0.0 landed on the reconnect parameter, so a single 30s ping timeout - a
routine hiccup - exited the process instead of reconnecting. The same
override also passed its bool into super().disconnect()'s wait: float.
Split the two concerns: shutdown() is the deliberate teardown (hangup
command, KeyboardInterrupt, action queue channel closed), disconnect()
is left to slixmpp.
That alone would leave the bot idle after a dropped connection, because
slixmpp does not reconnect an established stream on its own -
connection_made() clears _current_connection_attempt, so the later
connection_lost() only fires 'disconnected' and reschedule_connection_
attempt() bails on its is-None guard. So hook 'disconnected' and
reconnect ourselves, with a 1s..300s back-off reset on session_start, so
a server that accepts TCP but kills the stream (auth failure) doesn't
become a hot loop. When slixmpp is already retrying - its own reconnect()
path, or a _connect_loop still in flight - we stay out of the way rather
than cancelling that attempt with a competing connect().
session_start fires again on every reconnect, so guard
initialize_actionworker(): the action worker holds its own broker
connection that survived the c2s drop, and starting it twice would put
two consumers on the action queue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QZhYrGpmCvZchZRJ6zJHUM