feat: compose-stack model + backup failure exposure (PR A) #9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/stack-model-and-failures"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Backend foundation (PR A of 2) for reorganizing the dashboard and View Backups around compose stacks, plus the new failure visibility feature.
What's here (backend only — no UI yet)
Container#stack— derives the compose stack:baktainer.stacklabel →com.docker.compose.project→ backup name. Reported per container in the node snapshot, so main can group by stack.backup_history.stackcolumn (guarded migration), threaded end to end (start_backup → complete/fail record → node event → main ingest). Historical rows keep their stack even if the container is later removed.error; addedrecent_failures+GET /api/backups/failuresso the dashboard can surface why a backup failed.Why grouping-by-container-in-stack is enough
Each db and each volume is already its own container (
authentik,authentik-redis,authentik-volumes-volumes, …), so one ✓/✗ per container in a stack == per-db/per-volume — no invasive artifact-granular recording needed.Next (PR B)
Dashboard: one row per stack, engine icons, ✓/✗ per container, failure button/modal (reads this endpoint); and the file-based per-stack View Backups.
Full suite green — 1125 examples. (Also fixed a few test doubles missing the new
:stackmessage; one crashed a worker thread and hung the integration workflow.)🤖 Generated with Claude Code