Reintentar el login para que un fallo de DNS no mate al bot

[Isma-L154]

Cierra #33.

El bot murió el 2026-09-11 a las 06:18 UTC con ClientConnectorDNSError y
disparó la alerta de Discord. unattended-upgrades reemplazó glibc — que
es el resolver de DNS — y needrestart reinició el bot dentro de esa ventana.
getaddrinfo("discord.com") devolvió EAI_AGAIN, la excepción salió de
main() y el proceso terminó con 1. Dos arranques murieron así antes de que el
tercero entrara.

319 tests pasando (antes 293). +406 líneas, −1.

Dónde estaba realmente el agujero

Client.start() es login() seguido de connect(). Leyendo discord.py, solo
la primera mitad estaba expuesta:

# discord/client.py
async def start(self, token, *, reconnect=True):
    await self.login(token)
    await self.connect(reconnect=reconnect)

connect(reconnect=True) ya es resiliente: su bucle captura
aiohttp.ClientError, OSError, HTTPException, GatewayNotFound,
ConnectionClosed y asyncio.TimeoutError, y reintenta con backoff propio. Un
gateway que se cae a mitad de canción ya se recuperaba solo.

login() no tiene reintento ninguno. Por eso unos segundos sin resolver
eran fatales, y por eso el traceback apuntaba a static_login → /users/@me.

Así que main() llama a las dos mitades por separado: el login se reintenta, y
el gateway se entrega a discord.py sin envolver — apilar nuestra política de
reintentos sobre la suya duplicaría cada espera.

Qué se reintenta y qué no

Sí	DNS (ClientConnectorDNSError), OSError, timeouts, GatewayNotFound, y los 5xx de Discord
No	LoginFailure, PrivilegedIntentsRequired, los 4xx, TypeError

Un token equivocado o un intent que falta es un error de despliegue: va a fallar
igual para siempre, y machacar el endpoint de login encima invita a un
rate-limit. Un 4xx es culpa nuestra y lo sigue siendo.

Backoff de 5s, 15s, 30s, 60s, 120s. Agotados los intentos se relanza el último
error, a propósito: systemd sigue siendo la red de seguridad. Reintentar para
siempre dejaría un bot que systemctl ve vivo, que nunca funciona y que nunca
dispara OnFailure. Un test fija ese presupuesto entre 60 y 600 segundos.

El bug que encontró el test de integración

Reintentar el login no es llamarlo dos veces, y uno de los tests lo demostró.

HTTPClient.static_login crea una aiohttp.ClientSession nueva en cada
llamada y abandona la anterior. Un reintento ingenuo filtra una sesión por
intento — justo el tipo de fuga lenta que el brief prohíbe en una caja de
768 MB.

Pero cerrarla tampoco basta. A la sesión se le pasa el connector del HTTPClient,
y el connector_owner=True por defecto de aiohttp significa que cerrar la
sesión cierra el connector compartido. Como ClientSession.closed consulta
el estado del connector:

# aiohttp/client.py
@property
def closed(self) -> bool:
    return self._connector is None or self._connector.closed

...toda sesión posterior construida sobre él nace cerrada, y el siguiente
intento muere con RuntimeError: Session is closed en vez de reintentar. Se
limpia el connector junto con la sesión para que se construya un par nuevo.

Ese bug era invisible para los tests con un HTTP falso. Solo apareció en el
que maneja un discord.Client real con sesiones aiohttp reales contra un
resolver parcheado para fallar, y que además afirma el invariante que importa:
ninguna sesión aiohttp queda abierta tras los reintentos.

Cómo probarlo

pytest                       # 319 pasando
pytest tests/test_startup.py # los 26 de este arreglo

Verificación de extremo a extremo ya hecha contra la API real — DNS forzado a
fallar dos veces y luego restaurado:

INFO    discord.client: logging in using static token
WARNING loopify.startup: Login failed (ClientConnectorDNSError: ... Temporary failure in name resolution) — retrying in 0s
INFO    discord.client: logging in using static token
WARNING loopify.startup: Login failed (ClientConnectorDNSError: ... Temporary failure in name resolution) — retrying in 0s
INFO    discord.client: logging in using static token

RESULTADO: DNS se recuperó tras 2 fallos; luego Discord rechazó el token falso SIN reintentar.

Reproducir el incidente entero en ilserver4, tras desplegar:

sudo systemctl stop systemd-resolved
sudo systemctl restart loopify-bot
journalctl -u loopify-bot -f      # debe registrar reintentos, NO salir con 1
sudo systemctl start systemd-resolved
                                  # debe conectarse solo, sin tocar nada

Lo que no se toca

La unidad de systemd. Un After=nss-lookup.target no habría evitado esto:
quien reinició el servicio fue needrestart a mitad del upgrade, con la máquina
ya arrancada hacía horas. Restart=on-failure sigue siendo el respaldo para
todo lo que no sea el login.