What was wrong:snapshot remove never checked the ID. For an ID that names no snapshot it deleted nothing, printed that the snapshot was removed from the local database and from the destination store, and exited 0, under --force, --json, --dry-run and --local-only alike. remote_removed was true whenever the delete did not fail, even when there was nothing to delete.
What changed:
Before the dry run and the confirmation prompt, the command looks the ID up in the local index. Only when the local index has no row, and --local-only is not set, does it look for the snapshot's metadata on the destination store. If it finds neither, it returns an error and prints nothing on stdout.
The local index is checked first so that a snapshot in it can still be removed while the destination store is unreachable, as before.
"Removed snapshot ... from local database" is printed only when the local index had the row. remote_removed is true only when metadata was actually deleted.
Two existing remove tests ran with no local index and so asserted the false "from local database" line. They now get a local index.
Judgement call: under --local-only the destination store is not consulted, so a snapshot that is only on the destination store is an error there.
Not changed: the confirmation prompt and the dry-run lines still name both the local database and the destination store, whichever of them holds the snapshot.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/293.
**What was wrong:** `snapshot remove` never checked the ID. For an ID that names no snapshot it deleted nothing, printed that the snapshot was removed from the local database and from the destination store, and exited 0, under `--force`, `--json`, `--dry-run` and `--local-only` alike. `remote_removed` was true whenever the delete did not fail, even when there was nothing to delete.
**What changed:**
- Before the dry run and the confirmation prompt, the command looks the ID up in the local index. Only when the local index has no row, and `--local-only` is not set, does it look for the snapshot's metadata on the destination store. If it finds neither, it returns an error and prints nothing on stdout.
- The local index is checked first so that a snapshot in it can still be removed while the destination store is unreachable, as before.
- "Removed snapshot ... from local database" is printed only when the local index had the row. `remote_removed` is true only when metadata was actually deleted.
- Two existing remove tests ran with no local index and so asserted the false "from local database" line. They now get a local index.
Judgement call: under `--local-only` the destination store is not consulted, so a snapshot that is only on the destination store is an error there.
Not changed: the confirmation prompt and the dry-run lines still name both the local database and the destination store, whichever of them holds the snapshot.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 05:12:44 +02:00
snapshot remove never checked that the ID existed: it deleted nothing,
reported the snapshot removed from the local database and from the
destination store, and exited 0, under --json, --dry-run and
--local-only too. It now looks the ID up in the local index and, only
when that has no row and --local-only is not set, on the destination
store; finding neither is an error. The command reports a removal from
the local database only when the local index had the row, and
remote_removed is true only when metadata was actually deleted.
Judgement call: under --local-only the destination store is not
consulted, so the snapshot must be in the local index.
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 #293.
What was wrong:
snapshot removenever checked the ID. For an ID that names no snapshot it deleted nothing, printed that the snapshot was removed from the local database and from the destination store, and exited 0, under--force,--json,--dry-runand--local-onlyalike.remote_removedwas true whenever the delete did not fail, even when there was nothing to delete.What changed:
--local-onlyis not set, does it look for the snapshot's metadata on the destination store. If it finds neither, it returns an error and prints nothing on stdout.remote_removedis true only when metadata was actually deleted.Judgement call: under
--local-onlythe destination store is not consulted, so a snapshot that is only on the destination store is an error there.Not changed: the confirmation prompt and the dry-run lines still name both the local database and the destination store, whichever of them holds the snapshot.
Model: opus-5-5
Review passed.
Model: opus-5-5