Commit Graph
2 Commits
Author SHA1 Message Date
2GT-RichandClaude Opus 5 1a4b635052 fix(firmware): halt-on-failure stopped waiting for the wave to finish (v0.24.5-beta)
CI / Deployment files in sync (push) Canceled after 0s
CI / Frontend — Lint, Type-check, Test & Build (push) Canceled after 0s
CI / Backend — Lint, Type-check & Build (push) Canceled after 0s
CI / Security Audit (push) Canceled after 0s
CodeQL Security Analysis / Analyze (javascript-typescript) (push) Canceled after 0s
Documentation / Build (check only) (push) Canceled after 0s
Documentation / Publish versioned site (push) Canceled after 0s
Publish to GHCR / Build & Push Backend (push) Canceled after 0s
Publish to GHCR / Build & Push Nginx (Frontend) (push) Canceled after 0s
Release / release (push) Canceled after 0s
A regression I introduced in v0.24.3, and described inaccurately in its own
commit message.

Adding concurrency moved the halt check to the end of a wave. I wrote that
"at the default of 1 those are the same moment". That is only true of a wave
holding one device. With several devices in one wave and the default
sequential setting, the old code stopped the moment one failed; mine went on
to attempt every remaining device in that wave first. Anyone relying on
halt-on-failure with a wide wave 1 got a wider blast radius than before,
without changing a setting.

Halting now stops further devices from *starting* as soon as a failure is
known, whatever the concurrency. Devices already in flight are allowed to
finish, because interrupting one mid-write is how you brick it. At
concurrency 1 that is precisely the previous behaviour. Above 1, only the
devices genuinely running side by side can carry a bad build -- which is the
unavoidable part of the trade in #135, rather than a cost imposed on rollouts
that never asked for concurrency.

The firmware documentation said the same wrong thing and is corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-08 08:54:51 -07:00
2GT-RichandClaude Opus 5 6c3d2aaa35 docs: firmware rollouts and backups
Neither area had a page, and both changed materially in v0.24.2/v0.24.3.

The firmware page records why the pipeline downloads and verifies before
rebooting, and what raising "at once" actually costs: halting becomes less
precise, devices reboot together, and the upstream warning is conservative
enough that its absence is not proof of safety.

The backups page leads with the fact that a backup is /export text rather
than a binary blob, since that is what makes preview and diff possible and
what limits what a restore can do. It also states plainly that a backup and
its Config History snapshot are one artifact, so deleting one removes the
other's rollback.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 21:42:55 -07:00