What is wrong:deleteUnreferencedBlobs (internal/vaultik/prune.go) logs each failed blob delete and counts it in BlobsFailed, but PruneBlobs still returns nil. removeAllLocalSnapshots and removeAllOrphanRemotes (internal/vaultik/snapshot.go) count failed metadata deletes and only warn. After either kind of failure, NukeRemote still prints "Backup destination store is now empty." The nuke warning also says "Run 'vaultik prune' once the remote is healthy", but prune never removes metadata (#251 fixed the same advice in snapshot remove).
How it was shown: with one blob's directory made read-only, prune --json printed "blobs_failed": 1 and exited 0. remote nuke --force printed "Failed to delete 1 blob(s)", then "Backup destination store is now empty.", exited 0, and left the blob. With one metadata directory read-only instead, nuke warned, printed "now empty", exited 0 and left four files.
Definition of done
prune (with and without --json, and the prune step of snapshot create --prune) exits non-zero when any blob delete fails; the --json document is still printed.
remote nuke exits non-zero when any delete fails, does not print that the store is empty, and its advice names a command that does remove what was left (running remote nuke again), not prune.
A successful remote nuke prints no prune advice either: today it reuses RemoveAllSnapshots, which prints "Note: Removed snapshots' blobs remain on the remote. Run 'vaultik prune' ..." before nuke deletes those blobs itself.
Tests cover a failed blob delete for prune and failed blob and metadata deletes for remote nuke.
Model: opus-5-5
Found by the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 (part 4).
**What is wrong:** `deleteUnreferencedBlobs` (`internal/vaultik/prune.go`) logs each failed blob delete and counts it in `BlobsFailed`, but `PruneBlobs` still returns nil. `removeAllLocalSnapshots` and `removeAllOrphanRemotes` (`internal/vaultik/snapshot.go`) count failed metadata deletes and only warn. After either kind of failure, `NukeRemote` still prints "Backup destination store is now empty." The nuke warning also says "Run 'vaultik prune' once the remote is healthy", but `prune` never removes metadata (https://git.eeqj.de/sneak/vaultik/issues/251 fixed the same advice in `snapshot remove`).
**How it was shown:** with one blob's directory made read-only, `prune --json` printed `"blobs_failed": 1` and exited 0. `remote nuke --force` printed "Failed to delete 1 blob(s)", then "Backup destination store is now empty.", exited 0, and left the blob. With one metadata directory read-only instead, nuke warned, printed "now empty", exited 0 and left four files.
**Definition of done**
- `prune` (with and without `--json`, and the prune step of `snapshot create --prune`) exits non-zero when any blob delete fails; the `--json` document is still printed.
- `remote nuke` exits non-zero when any delete fails, does not print that the store is empty, and its advice names a command that does remove what was left (running `remote nuke` again), not `prune`.
- A successful `remote nuke` prints no `prune` advice either: today it reuses `RemoveAllSnapshots`, which prints "Note: Removed snapshots' blobs remain on the remote. Run 'vaultik prune' ..." before nuke deletes those blobs itself.
- Tests cover a failed blob delete for `prune` and failed blob and metadata deletes for `remote nuke`.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:29:18 +02:00
Built in #336: prune (also under --json and snapshot create --prune) and remote nuke now exit non-zero when a delete fails. Nuke no longer reports the store empty on failure, says to run vaultik remote nuke --force again, and no longer advises prune after a successful run.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/vaultik/pulls/336: `prune` (also under `--json` and `snapshot create --prune`) and `remote nuke` now exit non-zero when a delete fails. Nuke no longer reports the store empty on failure, says to run `vaultik remote nuke --force` again, and no longer advises `prune` after a successful run.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found by the defect hunt in #288 (part 4).
What is wrong:
deleteUnreferencedBlobs(internal/vaultik/prune.go) logs each failed blob delete and counts it inBlobsFailed, butPruneBlobsstill returns nil.removeAllLocalSnapshotsandremoveAllOrphanRemotes(internal/vaultik/snapshot.go) count failed metadata deletes and only warn. After either kind of failure,NukeRemotestill prints "Backup destination store is now empty." The nuke warning also says "Run 'vaultik prune' once the remote is healthy", butprunenever removes metadata (#251 fixed the same advice insnapshot remove).How it was shown: with one blob's directory made read-only,
prune --jsonprinted"blobs_failed": 1and exited 0.remote nuke --forceprinted "Failed to delete 1 blob(s)", then "Backup destination store is now empty.", exited 0, and left the blob. With one metadata directory read-only instead, nuke warned, printed "now empty", exited 0 and left four files.Definition of done
prune(with and without--json, and the prune step ofsnapshot create --prune) exits non-zero when any blob delete fails; the--jsondocument is still printed.remote nukeexits non-zero when any delete fails, does not print that the store is empty, and its advice names a command that does remove what was left (runningremote nukeagain), notprune.remote nukeprints nopruneadvice either: today it reusesRemoveAllSnapshots, which prints "Note: Removed snapshots' blobs remain on the remote. Run 'vaultik prune' ..." before nuke deletes those blobs itself.pruneand failed blob and metadata deletes forremote nuke.Model: opus-5-5
Built in #336:
prune(also under--jsonandsnapshot create --prune) andremote nukenow exit non-zero when a delete fails. Nuke no longer reports the store empty on failure, says to runvaultik remote nuke --forceagain, and no longer advisespruneafter a successful run.Model: opus-5-5