Reconecta el stream de caídas cuando muere en Python

Todo stream de larga vida termina alguna vez: la red parpadea, el servidor te expulsa por inactividad, tu host se reinicia. El listener que sobrevive no es el que nunca se desconecta; es el que reconecta limpio. Aquí está el patrón que mantiene el listener de Python vivo durante semanas.

El fallo es normal

El listener del quickstart de Python mantiene una solicitud HTTP abierta y lee líneas data: conforme llegan, verificado el 2026-10-17. Cuando la conexión muere, el bucle de lectura termina con una excepción o un iterador atascado, y la reacción equivocada es romperse o martillear el endpoint con reintentos instantáneos. La reacción correcta es una pausa creciente y una conexión nueva.

El patrón de reconexión

Envuelve el listener en un bucle externo con un retraso que se duplica tras cada fallo y se reinicia tras un tramo de éxito:

delay = 1
while True:
    try:
        listen()          # the stream loop; returns when it ends
        delay = 1         # it ran fine: reset
    except Exception as exc:
        print("stream ended:", exc)
    time.sleep(delay)
    delay = min(delay * 2, 60)

Observar el propio retraso crecer durante un mes es una señal en sí misma, porque un tope que sigues subiendo sin notarlo es una agenda derivando. El tope importa tanto como la duplicación: un tope de 60 segundos evita que una mala noche se vuelva un hueco de 15 minutos entre intentos, y el reinicio tras el éxito evita que una buena semana acumule un retraso largo.

Lo que una reconexión pierde, y qué hacer

Cualquier cosa que cayó mientras estabas desconectado se fue del stream; los streams no repiten. Si el hueco importa a tu aplicación, rellénalo después desde el endpoint de caídas, que el quickstart de curl cubre para caídas recientes bajo demanda. Si no importa, retoma y deja que llegue la siguiente caída.

En una reconexión también recibes un nuevo mensaje de control connected, así que tu parser lo ve otra vez: manéjalo igual cada vez, y un segundo saludo no cambia nada.

Cuando las propias reconexiones son el problema

Un listener que reconecta cada pocos minutos te está diciendo algo: la red, el proxy, o el endpoint. Registra cada reconexión con el tiempo desde la última, y una semana de logs separa un enlace sano de uno enfermo. Si los fallos se agrupan a una hora del día, la respuesta es infraestructura, no código.

Bucle externo, pausa creciente, tope de 60 segundos, hueco rellenado si importa. El stream te va a soltar; el listener decide si alguien lo nota.