After Ctrl-C or SIGTERM, phase 2 of a --skip-errors backup treated the cancellation error from each remaining file like an unreadable file: it opened the file, printed an error line, counted it as failed and moved on to the next.
Two changes in internal/snapshot/scanner.go:
processPhase checks for cancellation before each file, as the scan phase already does.
processFileWithErrorHandling stops the run on any file error once the run is cancelled, ahead of the --skip-errors branch.
The second check covers the file being read when the cancel lands. The first covers an empty file, which has no chunks: nothing reads the context while it is backed up, so without the loop check the run would still open the next file before noticing.
The new test cancels a run in both places and checks that the scan returns context.Canceled, opens no file after the cancel and prints no error line. runSkipErrorScan now takes the context, so its other callers pass context.Background().
What the diff does not show: on next the cancelled scan returned no error at all after skipping every remaining file. Only the command layer, which watches for the signal itself, reported the run as interrupted.
Judgement call: when a file fails for its own reason after the run is cancelled, the run returns that file's error rather than the bare cancellation error. It stops either way.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/286.
After Ctrl-C or SIGTERM, phase 2 of a `--skip-errors` backup treated the cancellation error from each remaining file like an unreadable file: it opened the file, printed an error line, counted it as failed and moved on to the next.
Two changes in `internal/snapshot/scanner.go`:
- `processPhase` checks for cancellation before each file, as the scan phase already does.
- `processFileWithErrorHandling` stops the run on any file error once the run is cancelled, ahead of the `--skip-errors` branch.
The second check covers the file being read when the cancel lands. The first covers an empty file, which has no chunks: nothing reads the context while it is backed up, so without the loop check the run would still open the next file before noticing.
The new test cancels a run in both places and checks that the scan returns `context.Canceled`, opens no file after the cancel and prints no error line. `runSkipErrorScan` now takes the context, so its other callers pass `context.Background()`.
What the diff does not show: on `next` the cancelled scan returned no error at all after skipping every remaining file. Only the command layer, which watches for the signal itself, reported the run as interrupted.
Judgement call: when a file fails for its own reason after the run is cancelled, the run returns that file's error rather than the bare cancellation error. It stops either way.
Model: opus-5-5
After Ctrl-C or SIGTERM, phase 2 of a --skip-errors backup treated the
cancellation error from each remaining file like an unreadable file: it
opened the file, printed an error line, counted it as failed and moved
on to the next. The processing loop now checks for cancellation before
each file, and an error from a file once the run is cancelled stops the
run instead of being skipped. The loop check is what stops a run
cancelled while an empty file is open, since an empty file has no
chunks and nothing reads the context while it is backed up.
The --skip-errors test helper now takes the scan's context.
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 #286.
After Ctrl-C or SIGTERM, phase 2 of a
--skip-errorsbackup treated the cancellation error from each remaining file like an unreadable file: it opened the file, printed an error line, counted it as failed and moved on to the next.Two changes in
internal/snapshot/scanner.go:processPhasechecks for cancellation before each file, as the scan phase already does.processFileWithErrorHandlingstops the run on any file error once the run is cancelled, ahead of the--skip-errorsbranch.The second check covers the file being read when the cancel lands. The first covers an empty file, which has no chunks: nothing reads the context while it is backed up, so without the loop check the run would still open the next file before noticing.
The new test cancels a run in both places and checks that the scan returns
context.Canceled, opens no file after the cancel and prints no error line.runSkipErrorScannow takes the context, so its other callers passcontext.Background().What the diff does not show: on
nextthe cancelled scan returned no error at all after skipping every remaining file. Only the command layer, which watches for the signal itself, reported the run as interrupted.Judgement call: when a file fails for its own reason after the run is cancelled, the run returns that file's error rather than the bare cancellation error. It stops either way.
Model: opus-5-5
Review passed.
Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.