What is wrong:RemoveAllSnapshots (internal/vaultik/snapshot.go) turns a failed listing of the destination into a warning, so that a local-only remove is not blocked; but remote nuke is not local-only. executeRemoveAll then deletes every local snapshot record although every remote delete fails, and CleanupOrphanedData drops every file, chunk and blob row. Only after that does PruneBlobs fail. The snapshots on the destination become remote-only rows whose names are lost, and prune never removes them.
How it was shown: with two snapshots, the destination directory was renamed (an unplugged volume) and remote nuke --force was run. It printed "Removed 2 snapshot(s)" and the prune advice, then "Remote nuke failed", and exited 1. The local index then held 0 snapshots, 0 files and 0 blobs; with the directory back, the store still held all six objects.
Definition of done
When remote nuke cannot list the destination it stops with a non-zero exit before it changes the local index. The same holds for a destination the marker from #239 shows as not present (local snapshots recorded, no marker), such as an unplugged mount point, where nuke today clears the local records.
It drops the local record of a snapshot only once that snapshot's remote metadata is deleted.
snapshot remove --local-only keeps working with an unreachable destination.
A test covers nuke against a destination that cannot be listed and checks the local index is unchanged.
Model: opus-5-5
Found by the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 (part 4).
**What is wrong:** `RemoveAllSnapshots` (`internal/vaultik/snapshot.go`) turns a failed listing of the destination into a warning, so that a local-only remove is not blocked; but `remote nuke` is not local-only. `executeRemoveAll` then deletes every local snapshot record although every remote delete fails, and `CleanupOrphanedData` drops every file, chunk and blob row. Only after that does `PruneBlobs` fail. The snapshots on the destination become remote-only rows whose names are lost, and `prune` never removes them.
**How it was shown:** with two snapshots, the destination directory was renamed (an unplugged volume) and `remote nuke --force` was run. It printed "Removed 2 snapshot(s)" and the prune advice, then "Remote nuke failed", and exited 1. The local index then held 0 snapshots, 0 files and 0 blobs; with the directory back, the store still held all six objects.
**Definition of done**
- When `remote nuke` cannot list the destination it stops with a non-zero exit before it changes the local index. The same holds for a destination the marker from https://git.eeqj.de/sneak/vaultik/issues/239 shows as not present (local snapshots recorded, no marker), such as an unplugged mount point, where nuke today clears the local records.
- It drops the local record of a snapshot only once that snapshot's remote metadata is deleted.
- `snapshot remove --local-only` keeps working with an unreachable destination.
- A test covers nuke against a destination that cannot be listed and checks the local index is unchanged.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:29:20 +02:00
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:
RemoveAllSnapshots(internal/vaultik/snapshot.go) turns a failed listing of the destination into a warning, so that a local-only remove is not blocked; butremote nukeis not local-only.executeRemoveAllthen deletes every local snapshot record although every remote delete fails, andCleanupOrphanedDatadrops every file, chunk and blob row. Only after that doesPruneBlobsfail. The snapshots on the destination become remote-only rows whose names are lost, andprunenever removes them.How it was shown: with two snapshots, the destination directory was renamed (an unplugged volume) and
remote nuke --forcewas run. It printed "Removed 2 snapshot(s)" and the prune advice, then "Remote nuke failed", and exited 1. The local index then held 0 snapshots, 0 files and 0 blobs; with the directory back, the store still held all six objects.Definition of done
remote nukecannot list the destination it stops with a non-zero exit before it changes the local index. The same holds for a destination the marker from #239 shows as not present (local snapshots recorded, no marker), such as an unplugged mount point, where nuke today clears the local records.snapshot remove --local-onlykeeps working with an unreachable destination.Model: opus-5-5