v0.25.1
Released: 2026-04-26 · Channel: stable · Breaking: no
Summary
Two customer-blocking bugs surfaced by the first real apply test on the v0.25.0 release, both in the managed-update pipeline machinery itself rather than in the chat application. v0.25.1 closes both. No protocol changes; existing data unaffected.
Fixed
Admin Updates UI no longer hangs on “Waiting for first state update…” (CHAT-108)
The chatalot-server polls the chatalot-updater sidecar every 3
seconds during an apply to surface progress in the admin UI. The
server’s deserializer for the sidecar’s
/v1/apply/:id response required a JSON field named
apply_id; the sidecar emits it as id. Every
poll returned HTTP 500 server-side, the UI never advanced past
“Waiting for first state update…” even when the
apply was completing cleanly underneath. The customer experience was
“click Apply, watch UI hang forever, eventually email
support.”
Server’s deserializer now accepts both names via
#[serde(rename = "id", alias = "apply_id")],
plus the same treatment for current_state /
state. A regression test
(parses_sidecar_v1_apply_response_shape) pins both wire
formats so any future drift fails CI rather than the UI.
First apply no longer fails on snapshot creation (CHAT-107)
Docker Compose creates the chatalot_backups volume with
default root:root 755 ownership. The chatalot-updater
binary runs as uid=1001 (updater) and writes snapshots
into that directory before every apply. Without intervention the
first apply attempt aborted at snapshot creation with an opaque
“gzip writer task exited unexpectedly” error. The
pre-disruption abort was correct — the orchestrator did the
right thing — but the customer was left with no obvious
remediation path.
The chatalot-updater image now uses an entrypoint script that runs
briefly as root, chowns /var/backups/chatalot to the
updater uid, then exec’s the binary as the non-root user via
gosu. Self-healing on first start; no operator
coordination needed.
Upgrade path
- Managed-tier customers: the chatalot-server fix
(CHAT-108) ships through the standard apply flow — click Apply
in the admin Updates tab. The chatalot-updater fix (CHAT-107) ships
in a new sidecar image; the updater container has no managed-update
path of its own, so existing instances need a manual
docker compose pull chatalot-updater && docker compose up -d chatalot-updaterto pick up the new sidecar image. New bundle installs pick up both fixes automatically. - Self-host operators on the OSS path:
git pull && docker compose pull && docker compose up -das usual.
Release artifacts
Container images pushed to
registry.seglamater.app/seglamater/chatalot and
chatalot-updater, both cosign-signed against the
published public key. Manifest at
https://updates.seglamater.app/chatalot/channels/stable/latest.json
points to the v0.25.1 server image by digest.