What was wrong: When a snapshot was only on the destination store and deleting its metadata there failed, snapshot remove warned and exited 0 having removed nothing; the comment on removeSnapshotRemote justified that by a local removal that never happened on that path. The README and the help text promised the vaultik prune follow-up on every success; it is not printed under --local-only or --json, with an unreachable destination store, or when there was no metadata to remove.
What changed:
removeSnapshotRemote is told whether the snapshot was in the local index. If it was not, a failed delete is an error and the command exits non-zero. If it was, the local removal stands and the failed delete is a warning.
The --local-only skip moved from RemoveSnapshot into removeSnapshotRemote as an early return, keeping RemoveSnapshot within the linter's complexity limit.
The comments on both functions describe both cases; the one on removeSnapshotRemote says it returns true only when the delete finished without an error and removed at least one object.
The README and the help text say when the vaultik prune invocation is printed, and that a failed delete for a snapshot only on the destination store is an error.
New test for that failed delete under --force and --json, using the existing faultstore wrapper.
Partly verified: a delete that fails partway leaves some metadata objects deleted; running the command again finds the snapshot by the objects left and removes them. From reading the code, not tested.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/340.
**What was wrong:** When a snapshot was only on the destination store and deleting its metadata there failed, `snapshot remove` warned and exited 0 having removed nothing; the comment on `removeSnapshotRemote` justified that by a local removal that never happened on that path. The README and the help text promised the `vaultik prune` follow-up on every success; it is not printed under `--local-only` or `--json`, with an unreachable destination store, or when there was no metadata to remove.
**What changed:**
- `removeSnapshotRemote` is told whether the snapshot was in the local index. If it was not, a failed delete is an error and the command exits non-zero. If it was, the local removal stands and the failed delete is a warning.
- The `--local-only` skip moved from `RemoveSnapshot` into `removeSnapshotRemote` as an early return, keeping `RemoveSnapshot` within the linter's complexity limit.
- The comments on both functions describe both cases; the one on `removeSnapshotRemote` says it returns true only when the delete finished without an error and removed at least one object.
- The README and the help text say when the `vaultik prune` invocation is printed, and that a failed delete for a snapshot only on the destination store is an error.
- New test for that failed delete under `--force` and `--json`, using the existing `faultstore` wrapper.
Partly verified: a delete that fails partway leaves some metadata objects deleted; running the command again finds the snapshot by the objects left and removes them. From reading the code, not tested.
Model: opus-5-5
internal/vaultik/snapshot.go line 1385, the comment on removeSnapshotRemote: it now says the function "returns true when it deleted something". That is false when a delete fails partway. A snapshot's metadata is two objects, so one can be deleted before the delete of the other fails, and the function then returns false. The comment it replaces said "succeeded and deleted something". The definition of done in #340 requires this comment to be true on every path. Acceptable: say it returns true only when the delete finished without an error and removed at least one object.
Model: opus-5-5
- `internal/vaultik/snapshot.go` line 1385, the comment on `removeSnapshotRemote`: it now says the function "returns true when it deleted something". That is false when a delete fails partway. A snapshot's metadata is two objects, so one can be deleted before the delete of the other fails, and the function then returns false. The comment it replaces said "succeeded and deleted something". The definition of done in https://git.eeqj.de/sneak/vaultik/issues/340 requires this comment to be true on every path. Acceptable: say it returns true only when the delete finished without an error and removed at least one object.
Model: opus-5-5
When a snapshot was only on the destination store and deleting its
metadata there failed, snapshot remove warned and exited 0 having
removed nothing. That failure is now an error. A snapshot in the local
index keeps its behaviour: it is removed from the local index and the
failed delete on the destination store is a warning.
The README and the help text said the `vaultik prune` follow-up is
printed on every success; they now say it is printed only when metadata
was removed from the destination store, and never under --json. The
comments on RemoveSnapshot and removeSnapshotRemote describe both
cases; removeSnapshotRemote's also says it returns true only when the
delete finished without an error and removed at least one object.
Model: opus-5-5
The comment on removeSnapshotRemote now says it returns true only when the delete finished without an error and removed at least one object.
Rebased onto current next; commit message and PR body updated to match.
Model: opus-5-5
Rework:
- The comment on `removeSnapshotRemote` now says it returns true only when the delete finished without an error and removed at least one object.
- Rebased onto current `next`; commit message and PR body updated to match.
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 #340.
What was wrong: When a snapshot was only on the destination store and deleting its metadata there failed,
snapshot removewarned and exited 0 having removed nothing; the comment onremoveSnapshotRemotejustified that by a local removal that never happened on that path. The README and the help text promised thevaultik prunefollow-up on every success; it is not printed under--local-onlyor--json, with an unreachable destination store, or when there was no metadata to remove.What changed:
removeSnapshotRemoteis told whether the snapshot was in the local index. If it was not, a failed delete is an error and the command exits non-zero. If it was, the local removal stands and the failed delete is a warning.--local-onlyskip moved fromRemoveSnapshotintoremoveSnapshotRemoteas an early return, keepingRemoveSnapshotwithin the linter's complexity limit.removeSnapshotRemotesays it returns true only when the delete finished without an error and removed at least one object.vaultik pruneinvocation is printed, and that a failed delete for a snapshot only on the destination store is an error.--forceand--json, using the existingfaultstorewrapper.Partly verified: a delete that fails partway leaves some metadata objects deleted; running the command again finds the snapshot by the objects left and removes them. From reading the code, not tested.
Model: opus-5-5
internal/vaultik/snapshot.goline 1385, the comment onremoveSnapshotRemote: it now says the function "returns true when it deleted something". That is false when a delete fails partway. A snapshot's metadata is two objects, so one can be deleted before the delete of the other fails, and the function then returns false. The comment it replaces said "succeeded and deleted something". The definition of done in #340 requires this comment to be true on every path. Acceptable: say it returns true only when the delete finished without an error and removed at least one object.Model: opus-5-5
8e848c4cc7toc229d401c7c229d401c7tod9f1e5e78dd9f1e5e78dto973f6e12f6973f6e12f6toa146790f3fa146790f3fto693700dbc9Rework:
removeSnapshotRemotenow says it returns true only when the delete finished without an error and removed at least one object.next; commit message and PR body updated to match.Model: opus-5-5
Review passed.
Model: opus-5-5