1.7 KiB
Release v0.1.4 — the chat bridge learns to heal itself, method
The record lives in the operator's infra repo (
services/flybrain/release-v0.1.4.md), verbatim and dated. This file keeps only what the run established.
The fifth tagged release, and the fourth deployed to a container that was already
broadcasting. Read infra/docs/runbook.md's "Cutting a release" for the procedure, its
"Chat dead, bridge active" section for what this release ships, and
docs/design/stage-bridge.md section B5 for the design.
v0.1.4 is the first release that changes flybridge and the first that restarts
flypush, so it is the first one where the deploy could take chat or the push down
rather than just the sim.
What it shipped, and why: a connected EventSub websocket is not a working
subscription. Both sockets can drop, Twitch can refuse the re-created
channel.chat.message subscription with "number of websocket transports limit exceeded"
(429), and the bridge then sits active (running) with no chat subscription at all —
which is exactly what happened, for an hour. The bridge now exits 75 when that
subscription has been unconfirmed for EVENTSUB_GRACE_MS, and systemd restarts it with
a fresh transport; NOTICE_MIN_INTERVAL_MS keeps the self-healing restarts from turning
into chat spam. chatSubscriptionHealthy is the field to read — never
eventSubConnected on its own.
Two auth lessons from the same period, both now in the code: refresh before validating a stored token (a broadcaster token that expired while a previous process held a fresher one in memory fails startup with 401 in a crash loop), and persist refreshed tokens for both roles when one account holds both.