Reconnect the drop stream when it dies in Python

Every long-lived stream ends eventually: the network blips, the server idles you out, your host reboots. The listener that survives is not the one that never disconnects; it is the one that reconnects cleanly. Here is the pattern that keeps the Python listener alive for weeks.

The failure is normal

The Python quickstart's listener holds one HTTP request open and reads data: lines as they arrive, checked 2026-10-17. When the connection dies, the read loop ends with an exception or a stalled iterator, and the wrong reaction is to crash or to hammer the endpoint with instant retries. The right reaction is a growing pause and a fresh connection.

The reconnect pattern

Wrap the listener in an outer loop with a delay that doubles after each failure and resets after a successful stretch:

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)

Watching the delay itself grow over a month is its own signal, because a ceiling you keep raising without noticing is a schedule drifting. The cap matters as much as the doubling: a 60-second ceiling keeps a bad night from becoming a 15-minute hole between attempts, and the reset on success keeps a good week from accumulating a long delay.

What a reconnect loses, and what to do about it

Anything that fell while you were disconnected is gone from the stream; streams do not replay. If the gap matters to your application, fill it afterward from the drops endpoint, which the curl quickstart covers for recent drops on request. If it does not, resume and let the next drop arrive.

On a reconnect you also get a fresh connected control message, so your parser sees it again: handle it the same way every time, and a second greeting changes nothing.

When the reconnects themselves are the problem

A listener that reconnects every few minutes is telling you something: the network, the proxy, or the endpoint. Log each reconnect with the time since the last one, and a week of logs separates a healthy link from a sick one. If the failures cluster at one hour of day, the answer is infrastructure, not code.

Outer loop, growing pause, 60-second cap, gap filled if it matters. The stream will drop you; the listener decides whether anyone notices.