snapshot restore --skip-errors aborted when a blob could not be downloaded (missing, damaged, or failing its hash check), after restoring whichever files the restore plan reached first. Only errors from writing a file went through the skip path.
A blob download error is now handled per file: every pending file that references the blob goes through handleRestoreFileError, like every other restore error. With --skip-errors those files are reported as failed and dropped from the restore plan, the remaining files are restored, and the command still exits non-zero. Without the flag the restore aborts at the first of those files.
What the diff does not show:
After a blob fails, the rest of its blob set is not downloaded then; any other file that needs those blobs gets them on a later pick.
A download error caused by cancelling the restore is not treated as a bad blob; the restore ends at once and reports no file as failed.
A failed file keeps its blobs in the restore cache until the restore ends, as failed files already did.
New tests: one deletes a blob from a two-blob snapshot and checks both modes; one cancels a --skip-errors restore mid-download.
Judgement call: without --skip-errors the abort error now also names one affected file and suggests --skip-errors; before, it named only the blob.
Judgement call: the --skip-errors help text and README now limit the packing and storage caveat to snapshot creation, since the help text read as covering restore too.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/218.
`snapshot restore --skip-errors` aborted when a blob could not be downloaded (missing, damaged, or failing its hash check), after restoring whichever files the restore plan reached first. Only errors from writing a file went through the skip path.
A blob download error is now handled per file: every pending file that references the blob goes through `handleRestoreFileError`, like every other restore error. With `--skip-errors` those files are reported as failed and dropped from the restore plan, the remaining files are restored, and the command still exits non-zero. Without the flag the restore aborts at the first of those files.
What the diff does not show:
- After a blob fails, the rest of its blob set is not downloaded then; any other file that needs those blobs gets them on a later pick.
- A download error caused by cancelling the restore is not treated as a bad blob; the restore ends at once and reports no file as failed.
- A failed file keeps its blobs in the restore cache until the restore ends, as failed files already did.
New tests: one deletes a blob from a two-blob snapshot and checks both modes; one cancels a `--skip-errors` restore mid-download.
Judgement call: without `--skip-errors` the abort error now also names one affected file and suggests `--skip-errors`; before, it named only the blob.
Judgement call: the `--skip-errors` help text and README now limit the packing and storage caveat to snapshot creation, since the help text read as covering restore too.
Model: opus-5-5
internal/vaultik/restore.go:446-448: the new check that ends a cancelled restore without failing the files of the blob being downloaded has no test, so nothing stops a Ctrl-C under --skip-errors from being reported as a list of failed files. Acceptable: a test in internal/vaultik/restore_skip_errors_test.go that cancels a SkipErrors restore while a blob download is in progress and asserts that Restore returns context.Canceled and reports no file as failed.
Model: opus-5-5
1. `internal/vaultik/restore.go:446-448`: the new check that ends a cancelled restore without failing the files of the blob being downloaded has no test, so nothing stops a Ctrl-C under `--skip-errors` from being reported as a list of failed files. Acceptable: a test in `internal/vaultik/restore_skip_errors_test.go` that cancels a `SkipErrors` restore while a blob download is in progress and asserts that `Restore` returns `context.Canceled` and reports no file as failed.
Model: opus-5-5
Added TestRestoreSkipErrorsCancelDuringBlobDownload: it cancels a SkipErrors restore while a blob download is in progress and asserts that Restore returns context.Canceled and that the file needing the blob is not reported as failed; with the cancel check removed it fails. Judgement call: it is in internal/vaultik/restore_interrupt_test.go, not restore_skip_errors_test.go, so it can reuse that file's store that holds a blob download open until cancel; the two files are in different test packages.
Model: opus-5-5
1. Added `TestRestoreSkipErrorsCancelDuringBlobDownload`: it cancels a `SkipErrors` restore while a blob download is in progress and asserts that `Restore` returns `context.Canceled` and that the file needing the blob is not reported as failed; with the cancel check removed it fails. Judgement call: it is in `internal/vaultik/restore_interrupt_test.go`, not `restore_skip_errors_test.go`, so it can reuse that file's store that holds a blob download open until cancel; the two files are in different test packages.
Model: opus-5-5
The branch no longer merges into current next. TODO.md:25 (top of Completed Steps) conflicts: next now opens that list with the entry for #213, and this branch adds its own entry at the same spot. Acceptable: rebase onto current next, keeping both entries.
Model: opus-5-5
1. The branch no longer merges into current `next`. `TODO.md:25` (top of Completed Steps) conflicts: `next` now opens that list with the entry for https://git.eeqj.de/sneak/vaultik/issues/213, and this branch adds its own entry at the same spot. Acceptable: rebase onto current `next`, keeping both entries.
Model: opus-5-5
A blob that failed to download ended `snapshot restore` even with
--skip-errors, after restoring whichever files came first. The download
error now goes through the same per-file handling as any other restore
error, once for every pending file that references the blob. With
--skip-errors those files are reported as failed, the rest are
restored, and the command still exits non-zero. Without the flag the
restore still aborts; the error now also names one affected file and
suggests --skip-errors. A cancelled restore still ends at once. The
--skip-errors help text and README now limit the packing and storage
caveat to snapshot creation.
Model: opus-5-5
Rebased onto current next; TODO.md keeps both entries, this one above the entry for #213. Nothing else changed.
Model: opus-5-5
1. Rebased onto current `next`; `TODO.md` keeps both entries, this one above the entry for https://git.eeqj.de/sneak/vaultik/issues/213. Nothing else changed.
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 #218.
snapshot restore --skip-errorsaborted when a blob could not be downloaded (missing, damaged, or failing its hash check), after restoring whichever files the restore plan reached first. Only errors from writing a file went through the skip path.A blob download error is now handled per file: every pending file that references the blob goes through
handleRestoreFileError, like every other restore error. With--skip-errorsthose files are reported as failed and dropped from the restore plan, the remaining files are restored, and the command still exits non-zero. Without the flag the restore aborts at the first of those files.What the diff does not show:
New tests: one deletes a blob from a two-blob snapshot and checks both modes; one cancels a
--skip-errorsrestore mid-download.Judgement call: without
--skip-errorsthe abort error now also names one affected file and suggests--skip-errors; before, it named only the blob.Judgement call: the
--skip-errorshelp text and README now limit the packing and storage caveat to snapshot creation, since the help text read as covering restore too.Model: opus-5-5
internal/vaultik/restore.go:446-448: the new check that ends a cancelled restore without failing the files of the blob being downloaded has no test, so nothing stops a Ctrl-C under--skip-errorsfrom being reported as a list of failed files. Acceptable: a test ininternal/vaultik/restore_skip_errors_test.gothat cancels aSkipErrorsrestore while a blob download is in progress and asserts thatRestorereturnscontext.Canceledand reports no file as failed.Model: opus-5-5
c7890953b5to7a40125c80TestRestoreSkipErrorsCancelDuringBlobDownload: it cancels aSkipErrorsrestore while a blob download is in progress and asserts thatRestorereturnscontext.Canceledand that the file needing the blob is not reported as failed; with the cancel check removed it fails. Judgement call: it is ininternal/vaultik/restore_interrupt_test.go, notrestore_skip_errors_test.go, so it can reuse that file's store that holds a blob download open until cancel; the two files are in different test packages.Model: opus-5-5
next.TODO.md:25(top of Completed Steps) conflicts:nextnow opens that list with the entry for #213, and this branch adds its own entry at the same spot. Acceptable: rebase onto currentnext, keeping both entries.Model: opus-5-5
7a40125c80toab737af4cdnext;TODO.mdkeeps both entries, this one above the entry for #213. Nothing else changed.Model: opus-5-5
Review passed.
Model: opus-5-5