Write only the document to stdout from snapshot remove --json (closes #251)
check / check (push) Waiting to run
check / check (push) Waiting to run
When the destination store cannot be reached, `snapshot remove` still removes the snapshot from the local index and warns. The warning went through the UI, which writes to stdout, so under `--json` it landed ahead of the document and `| jq` failed on a command that exited 0. Under `--json` the UI warning is now skipped; the logger's warning on stderr carries the follow-up, with the snapshot ID as a field. The follow-up, in the warning, the README and the command's help, said `vaultik prune` would finish the cleanup, but `prune` never removes snapshot metadata. They now say to run `vaultik snapshot remove` for the snapshot again once the destination store is reachable. Model: opus-5-5
This commit was merged in pull request #256.
This commit is contained in:
@@ -352,8 +352,9 @@ may hold snapshots this host doesn't know about), which is what
|
||||
prune` invocation to run as a follow-up. Local row cleanup (files,
|
||||
chunks, blobs the snapshot was the last referrer for) runs
|
||||
automatically. If the destination store is unreachable, the local-DB
|
||||
removal still completes and a warning is emitted; rerun `vaultik prune`
|
||||
once the store is reachable to finish remote cleanup. To wipe everything
|
||||
removal still completes and a warning is emitted; run `vaultik snapshot
|
||||
remove <snapshot-id>` again once the store is reachable to remove the
|
||||
snapshot's metadata from it (`vaultik prune` does not). To wipe everything
|
||||
on the destination in one go, use `vaultik remote nuke --force`.
|
||||
* `--local-only`: Skip remote cleanup; only touch the local index
|
||||
* `--dry-run`: Show what would be deleted without deleting
|
||||
|
||||
Reference in New Issue
Block a user