What was wrong: when snapshot purge, or the purge step of snapshot create --prune, could not delete a snapshot from the local index, it logged the error, deleted that snapshot's metadata from the destination store anyway, and exited 0. The local index was left with a record whose metadata was gone.
What changed: the purge now stops at the first snapshot it cannot delete from the local index and returns an error before touching that snapshot's remote metadata, so the command exits non-zero. snapshot create --prune runs the same purge, and a failed post-backup prune already makes it exit non-zero.
Stops rather than carries on: the same loop already stops when deleting a snapshot's remote metadata fails, so both failures now behave alike. Snapshots purged before the failing one stay purged locally and remotely. The cleanup of orphaned local rows that normally follows a purge is skipped on that run, as it already was after a remote failure; the next backup or purge does it.
Partly verified: the test drives snapshot purge only. The database trigger it uses to make the local index refuse the delete also breaks the backup's metadata export, which deletes the other snapshots from its copy of the local index, so snapshot create --prune is covered through the shared purge code, not by a test of its own.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/337.
**What was wrong:** when `snapshot purge`, or the purge step of `snapshot create --prune`, could not delete a snapshot from the local index, it logged the error, deleted that snapshot's metadata from the destination store anyway, and exited 0. The local index was left with a record whose metadata was gone.
**What changed:** the purge now stops at the first snapshot it cannot delete from the local index and returns an error before touching that snapshot's remote metadata, so the command exits non-zero. `snapshot create --prune` runs the same purge, and a failed post-backup prune already makes it exit non-zero.
**Stops rather than carries on:** the same loop already stops when deleting a snapshot's remote metadata fails, so both failures now behave alike. Snapshots purged before the failing one stay purged locally and remotely. The cleanup of orphaned local rows that normally follows a purge is skipped on that run, as it already was after a remote failure; the next backup or purge does it.
Partly verified: the test drives `snapshot purge` only. The database trigger it uses to make the local index refuse the delete also breaks the backup's metadata export, which deletes the other snapshots from its copy of the local index, so `snapshot create --prune` is covered through the shared purge code, not by a test of its own.
Model: opus-5-5
snapshot purge, and the purge step of snapshot create --prune, logged a
failure to delete a snapshot from the local index, deleted that
snapshot's metadata from the destination store anyway, and exited 0. The
purge now stops at that snapshot with an error before touching its
remote metadata, so the command exits non-zero. Stopping matches what
the same loop already does when the remote delete fails; snapshots
purged before the failure stay purged.
The test drives snapshot purge only: the trigger that makes the local
index refuse the delete also breaks the backup's metadata export, so
snapshot create --prune cannot be tested that way.
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 #337.
What was wrong: when
snapshot purge, or the purge step ofsnapshot create --prune, could not delete a snapshot from the local index, it logged the error, deleted that snapshot's metadata from the destination store anyway, and exited 0. The local index was left with a record whose metadata was gone.What changed: the purge now stops at the first snapshot it cannot delete from the local index and returns an error before touching that snapshot's remote metadata, so the command exits non-zero.
snapshot create --pruneruns the same purge, and a failed post-backup prune already makes it exit non-zero.Stops rather than carries on: the same loop already stops when deleting a snapshot's remote metadata fails, so both failures now behave alike. Snapshots purged before the failing one stay purged locally and remotely. The cleanup of orphaned local rows that normally follows a purge is skipped on that run, as it already was after a remote failure; the next backup or purge does it.
Partly verified: the test drives
snapshot purgeonly. The database trigger it uses to make the local index refuse the delete also breaks the backup's metadata export, which deletes the other snapshots from its copy of the local index, sosnapshot create --pruneis covered through the shared purge code, not by a test of its own.Model: opus-5-5
Review passed.
Model: opus-5-5