v2.12.0 — auto-update that actually works

[rancur]

auto_update_enabled has existed for a while. It could never have worked — three independent reasons, each sufficient on its own.

1. The version check was a string compare

update_available = latest != current and latest > current

"2.11.0" > "2.9.0" is False — at index 2, "1" < "9". So every x.9 → x.10+ upgrade was invisible. Worse, the reverse comparison was True, meaning the check could have offered a downgrade as an update.

Present in two places. routes/admin.py was fixed in 2.11.0; tasks/auto_update.py — the copy that actually schedules — was not. Fixed here, with 7 tests pinning the behaviour.

2. Nothing applied the update

scripts/auto-update.sh had to be installed in the host's crontab by hand. Nothing shipped it, so the signal file the worker wrote was never read by anything.

3. Even when triggered, it didn't update

That script ran docker compose up -d --build against the source already on disk — a rebuild of the same version.

---

waxflow-updater

A container cannot restart itself, so applying an update needs host-side Docker access. This is the only place WaxFlow asks for it, and it is deliberately constrained:

• network_mode: none. It never downloads anything. The worker (network, no socket) decides the target version; the Docker daemon fetches image layers when asked over the socket. Nothing with host-root access talks to the internet.
• Rollback. Health-checks the API afterwards and restores the previous tag if the new version doesn't come up. This runs unattended at 3am by default — an update that half-applies and is never noticed is worse than one that never ran.
• Untrusted input. The target tag comes from the GitHub API and is refused unless it matches semver, so nothing unexpected reaches docker pull.

Verified against a live Docker daemon:

test	result
malformed tag latest; rm -rf /	refused before any docker call
valid tag, image doesn't exist	fails cleanly, running stack untouched

Don't want to grant socket access? Delete the service — everything else keeps working, and the UI still tells you when a release is available.

Published images

Updating becomes a pull, not a rebuild. The rebuild path took ~25 minutes for the worker image on a Synology NAS and wedged the Docker daemon once; that is not acceptable for an unattended 3am job.

release-images.yml publishes ghcr.io/<owner>/waxflow-{api,worker,web} for amd64 + arm64 on each release, and refuses to publish if the tag disagrees with VERSION — an image whose baked /app/VERSION contradicts its tag would make the update check oscillate forever.

build: blocks remain, so docker compose up -d --build still works offline and for forks (WAXFLOW_REGISTRY).

Changed

• auto_update_enabled defaults to 1 for new installs only. INSERT OR IGNORE means existing deployments keep whatever they already had — nobody gets unattended updates switched on behind their back.

Tests

17 pass (10 sync_gate + 7 version compare), including the exact regression and a guard that a downgrade is never offered.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HmUiLHPmKoz215WAWV5eHe