fix: dashboard pills show every backed-up target (incl. volumes) #13

Merged
james merged 2 commits from fix/dashboard-pill-coverage into main 2026-07-28 18:32:55 +00:00
Owner

You asked me to dig into the dashboard ✓/✗ pill coverage. The pill logic itself was correct, but the source was too narrow.

The gap

Pills were built only from the live snapshot (currently-discovered containers). So a target that has backups but isn't discovered right now — most commonly a separate volume container (stopped, or a snapshot hiccup) — got no pill, even though it's being backed up. Same fragility I just removed from the file view in #12.

The fix

Build the target set as the union of:

  • discovered containers (snapshot), and
  • any container with a backup record (the recent-backups feed already carries container_name, engine, and stack).

Engine/stack prefer the snapshot and fall back to the backup record; grouping and engine icons follow. So every db and every volume that attempted a backup gets a pill — success ✓, failed ✗ (click for the reason), never –. The stack's Run button disables only when no target has a runnable (discovered) container.

JS-only; no backend change.

Note on what pills can't fix by themselves

If a stack uses combined mode (one db container with baktainer.volumes.backup=true, no separate volume container), there's only one backup record per run, so the volume isn't a distinct target — it'd show one db pill. Separate volume containers (your *-volumes setup) each get their own pill. If some are still missing after this, it points at combined-mode or the volume container not being labelled baktainer.backup=true.

🤖 Generated with Claude Code

You asked me to dig into the dashboard ✓/✗ pill coverage. The pill logic itself was correct, but the **source** was too narrow. ## The gap Pills were built only from the **live snapshot** (currently-discovered containers). So a target that *has* backups but isn't discovered right now — most commonly a **separate volume container** (stopped, or a snapshot hiccup) — got no pill, even though it's being backed up. Same fragility I just removed from the file view in #12. ## The fix Build the target set as the **union** of: - discovered containers (snapshot), and - any container with a **backup record** (the recent-backups feed already carries `container_name`, `engine`, and `stack`). Engine/stack prefer the snapshot and fall back to the backup record; grouping and engine icons follow. So **every db and every volume that attempted a backup gets a pill** — success ✓, failed ✗ (click for the reason), never –. The stack's Run button disables only when no target has a runnable (discovered) container. JS-only; no backend change. ## Note on what pills can't fix by themselves If a stack uses **combined mode** (one db container with `baktainer.volumes.backup=true`, no separate volume container), there's only *one* backup record per run, so the volume isn't a distinct target — it'd show one db pill. Separate volume containers (your `*-volumes` setup) each get their own pill. If some are still missing after this, it points at combined-mode or the volume container not being labelled `baktainer.backup=true`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fix(ui): dashboard pills cover every backed-up target (volumes incl.)
All checks were successful
Build, Push & Deploy / build-and-push (pull_request) Has been skipped
Build, Push & Deploy / deploy (Media) (pull_request) Has been skipped
Build, Push & Deploy / deploy (citadel) (pull_request) Has been skipped
Build, Push & Deploy / test (pull_request) Successful in 1m4s
c58d6264c1
The per-stack ✓/✗ pills were built only from the live snapshot, so a target that
has backups but isn't currently discovered — most commonly a separate volume
container — showed no pill (or none at all), even though it's being backed up.

Build the target set as the UNION of discovered containers (snapshot) and any
container with a backup record (the recent-backups feed carries container_name,
engine and stack). Each target's engine/stack prefer the snapshot, falling back
to the backup record; grouping and engine icons follow. So every db and every
volume that attempted a backup gets a pill, with a clickable failure reason.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
feat: artifact-granular backup recording + devicon engine icons
All checks were successful
Build, Push & Deploy / build-and-push (pull_request) Has been skipped
Build, Push & Deploy / deploy (Media) (pull_request) Has been skipped
Build, Push & Deploy / deploy (citadel) (pull_request) Has been skipped
Build, Push & Deploy / test (pull_request) Successful in 1m4s
fe65fdd979
Artifact-granular recording (so combined db+volume shows as separate pills):
- Container#backup now returns one result per artifact (each db, each volume):
  { kind, target, engine, path, size, status, error }. Per-artifact failures are
  captured, not raised, so a db success + a volume failure are reported
  independently. Volume artifacts are keyed "<name>-volumes" in combined mode.
- BackupMonitor#record_artifact records one backup_history row + one event per
  artifact (with kind); finish_backup clears the container's running state. The
  schedule + manual paths iterate results and record each.
- backup_history gains a `kind` column (guarded migration), threaded through the
  event and main ingest. So each db and each volume gets its own ✓/✗ pill.

Engine icons → devicons (devicon.dev): monochrome "plain" glyphs, icon-only,
inherit the theme text colour (white on the dark dashboard); volume keeps 📦.

Full suite green (1130 examples).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
james merged commit da1af23783 into main 2026-07-28 18:32:55 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
james/baktainer!13
No description provided.