remote nuke runs the bulk snapshot remove, which turned a failed listing of the destination store into a warning so that a local-only remove would not be blocked. Nuke then cleared the local snapshot records. Against a destination it could not list, every remote delete then failed, and the snapshots were left on the store without their names. Against an unplugged volume's empty mount point (snapshots in the local index, no vaultik-destination.txt), it deleted nothing, printed "Backup destination store is now empty." and exited zero.
Nuke now fails on either before it removes anything, and without its advice to run it again: that run would fail the same way, and for the missing marker the error says to mount the volume.
The bulk remove fails on either too; only a local-only remove still goes on with a warning. snapshot remove --local-only does not use it and is unchanged.
Each snapshot's remote metadata is deleted before its local record, and the local record is dropped only once that delete succeeded. A local delete that fails after it leaves a local snapshot without remote metadata, which prune reconciles.
README (remote nuke, remote storage layout), ARCHITECTURE.md and docs/REPOSTRUCTURE.md now name remote nuke among the commands that fail without the marker.
Judgement call: to leave the advice off these two refusals, nuke lists the destination's snapshot metadata next to its binding check, before deleting; the bulk remove then lists it again.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/292.
`remote nuke` runs the bulk snapshot remove, which turned a failed listing of the destination store into a warning so that a local-only remove would not be blocked. Nuke then cleared the local snapshot records. Against a destination it could not list, every remote delete then failed, and the snapshots were left on the store without their names. Against an unplugged volume's empty mount point (snapshots in the local index, no `vaultik-destination.txt`), it deleted nothing, printed "Backup destination store is now empty." and exited zero.
- Nuke now fails on either before it removes anything, and without its advice to run it again: that run would fail the same way, and for the missing marker the error says to mount the volume.
- The bulk remove fails on either too; only a local-only remove still goes on with a warning. `snapshot remove --local-only` does not use it and is unchanged.
- Each snapshot's remote metadata is deleted before its local record, and the local record is dropped only once that delete succeeded. A local delete that fails after it leaves a local snapshot without remote metadata, which `prune` reconciles.
- README (`remote nuke`, remote storage layout), `ARCHITECTURE.md` and `docs/REPOSTRUCTURE.md` now name `remote nuke` among the commands that fail without the marker.
- No `TODO.md` entry: see https://git.eeqj.de/sneak/vaultik/issues/334.
Judgement call: to leave the advice off these two refusals, nuke lists the destination's snapshot metadata next to its binding check, before deleting; the bulk remove then lists it again.
Model: opus-5-5
NukeRemote in internal/vaultik/prune.go: on the two new refusals (a destination store that cannot be listed, and one without vaultik-destination.txt while the local index holds snapshots), nuke still warns "Run 'vaultik remote nuke --force' again to delete what is left on the backup destination store." Both refusals come before anything is deleted, so nothing is "left", and running nuke again fails the same way. For the missing marker, the warning also contradicts the error's own advice (mount the volume, or run vaultik database delete). The comment above the binding check in the same function says this advice must not follow an error raised before anything is deleted. Acceptable: these two refusals return without the warning, as the binding check does, and the two new tests check that the warning is absent.
Model: opus-5-5
- `NukeRemote` in `internal/vaultik/prune.go`: on the two new refusals (a destination store that cannot be listed, and one without `vaultik-destination.txt` while the local index holds snapshots), nuke still warns "Run 'vaultik remote nuke --force' again to delete what is left on the backup destination store." Both refusals come before anything is deleted, so nothing is "left", and running nuke again fails the same way. For the missing marker, the warning also contradicts the error's own advice (mount the volume, or run `vaultik database delete`). The comment above the binding check in the same function says this advice must not follow an error raised before anything is deleted. Acceptable: these two refusals return without the warning, as the binding check does, and the two new tests check that the warning is absent.
Model: opus-5-5
`remote nuke` took a destination store it could not list, or one
without `vaultik-destination.txt` while the local index held
snapshots, as a warning: it then cleared the local snapshot records,
and for an unplugged volume's empty mount point reported the store
empty and exited zero. Nuke now fails on either before it removes
anything, without its advice to run it again, which would fail the
same way. The bulk remove it runs fails on either too; only a
local-only remove still goes on with a warning. Nuke also deletes each
snapshot's remote metadata before its local record, so a failed delete
keeps the snapshot in the local index rather than leaving it on the
store as a remote-only snapshot.
Model: opus-5-5
NukeRemote now lists the destination's snapshot metadata next to its binding check, before deleting anything, and returns that error without the advice to run nuke again; this covers both the store that cannot be listed and the missing vaultik-destination.txt. Both new tests check that the advice is absent. The PR body's judgement call is updated to match.
Rebased onto the current next.
Model: opus-5-5
Rework:
- `NukeRemote` now lists the destination's snapshot metadata next to its binding check, before deleting anything, and returns that error without the advice to run nuke again; this covers both the store that cannot be listed and the missing `vaultik-destination.txt`. Both new tests check that the advice is absent. The PR body's judgement call is updated to match.
- Rebased onto the current `next`.
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.
Fixes #292.
remote nukeruns the bulk snapshot remove, which turned a failed listing of the destination store into a warning so that a local-only remove would not be blocked. Nuke then cleared the local snapshot records. Against a destination it could not list, every remote delete then failed, and the snapshots were left on the store without their names. Against an unplugged volume's empty mount point (snapshots in the local index, novaultik-destination.txt), it deleted nothing, printed "Backup destination store is now empty." and exited zero.snapshot remove --local-onlydoes not use it and is unchanged.prunereconciles.remote nuke, remote storage layout),ARCHITECTURE.mdanddocs/REPOSTRUCTURE.mdnow nameremote nukeamong the commands that fail without the marker.TODO.mdentry: see #334.Judgement call: to leave the advice off these two refusals, nuke lists the destination's snapshot metadata next to its binding check, before deleting; the bulk remove then lists it again.
Model: opus-5-5
NukeRemoteininternal/vaultik/prune.go: on the two new refusals (a destination store that cannot be listed, and one withoutvaultik-destination.txtwhile the local index holds snapshots), nuke still warns "Run 'vaultik remote nuke --force' again to delete what is left on the backup destination store." Both refusals come before anything is deleted, so nothing is "left", and running nuke again fails the same way. For the missing marker, the warning also contradicts the error's own advice (mount the volume, or runvaultik database delete). The comment above the binding check in the same function says this advice must not follow an error raised before anything is deleted. Acceptable: these two refusals return without the warning, as the binding check does, and the two new tests check that the warning is absent.Model: opus-5-5
b674f11819to523629f1a8Rework:
NukeRemotenow lists the destination's snapshot metadata next to its binding check, before deleting anything, and returns that error without the advice to run nuke again; this covers both the store that cannot be listed and the missingvaultik-destination.txt. Both new tests check that the advice is absent. The PR body's judgement call is updated to match.next.Model: opus-5-5
Review passed.
Model: opus-5-5