What was wrong: restore planning returned an error for the first file that needs a chunk no blob holds, and restoreAllFiles returned it at once. The file never reached handleRestoreFileError, so --skip-errors could not skip it and nothing was restored.
What changed:newRestorePlan now leaves such a file out of the plan and returns it, by file ID, with the reason (errPlanChunkMissing or errPlanBlobIDMissing). restoreAllFiles passes each one, in file order, to handleRestoreFileError before the restore loop starts. Under --skip-errors the file is reported and counted as failed, every other file is restored, and the command exits non-zero. Without the flag the restore still stops before any file is written. A database error while reading a file's chunks still ends planning.
The --skip-errors restore tests now share one backup helper. The new case removes one blob's snapshot_blobs and uploads rows from the local index and exports the snapshot metadata again, then restores with and without SkipErrors.
What a reader might trip over:
Without the flag the error changes from building restore plan: planning FILE: ... to the usual restoring FILE: ... (pass --skip-errors to continue past restore failures).
Judgement call: these files are reported before the "Restoring N files" line, so that without the flag the restore still stops before it begins.
With --verify such a file is reported again by verification: #323.
Unverified: the locked make check never got a turn on the shared host, so the reviewer's gate is the first full run on this commit.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/326.
**What was wrong:** restore planning returned an error for the first file that needs a chunk no blob holds, and `restoreAllFiles` returned it at once. The file never reached `handleRestoreFileError`, so `--skip-errors` could not skip it and nothing was restored.
**What changed:** `newRestorePlan` now leaves such a file out of the plan and returns it, by file ID, with the reason (`errPlanChunkMissing` or `errPlanBlobIDMissing`). `restoreAllFiles` passes each one, in file order, to `handleRestoreFileError` before the restore loop starts. Under `--skip-errors` the file is reported and counted as failed, every other file is restored, and the command exits non-zero. Without the flag the restore still stops before any file is written. A database error while reading a file's chunks still ends planning.
The `--skip-errors` restore tests now share one backup helper. The new case removes one blob's `snapshot_blobs` and `uploads` rows from the local index and exports the snapshot metadata again, then restores with and without `SkipErrors`.
**What a reader might trip over:**
- Without the flag the error changes from `building restore plan: planning FILE: ...` to the usual `restoring FILE: ... (pass --skip-errors to continue past restore failures)`.
- Judgement call: these files are reported before the "Restoring N files" line, so that without the flag the restore still stops before it begins.
- With `--verify` such a file is reported again by verification: https://git.eeqj.de/sneak/vaultik/issues/323.
- Unverified: the locked `make check` never got a turn on the shared host, so the reviewer's gate is the first full run on this commit.
Model: opus-5-5
Restore planning stopped at the first file needing a chunk that no blob
holds, so --skip-errors never saw that file and nothing was restored.
The planner now leaves such a file out of the plan and returns it with
the reason, and each one goes through handleRestoreFileError like any
other failed file: skipped and counted under --skip-errors, fatal
without it. The fatal error now suggests --skip-errors, as other restore
failures do.
The skip-errors tests now share one backup helper; the new case removes
a blob from the snapshot metadata and exports it again.
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 #326.
What was wrong: restore planning returned an error for the first file that needs a chunk no blob holds, and
restoreAllFilesreturned it at once. The file never reachedhandleRestoreFileError, so--skip-errorscould not skip it and nothing was restored.What changed:
newRestorePlannow leaves such a file out of the plan and returns it, by file ID, with the reason (errPlanChunkMissingorerrPlanBlobIDMissing).restoreAllFilespasses each one, in file order, tohandleRestoreFileErrorbefore the restore loop starts. Under--skip-errorsthe file is reported and counted as failed, every other file is restored, and the command exits non-zero. Without the flag the restore still stops before any file is written. A database error while reading a file's chunks still ends planning.The
--skip-errorsrestore tests now share one backup helper. The new case removes one blob'ssnapshot_blobsanduploadsrows from the local index and exports the snapshot metadata again, then restores with and withoutSkipErrors.What a reader might trip over:
building restore plan: planning FILE: ...to the usualrestoring FILE: ... (pass --skip-errors to continue past restore failures).--verifysuch a file is reported again by verification: #323.make checknever got a turn on the shared host, so the reviewer's gate is the first full run on this commit.Model: opus-5-5
Review passed.
Model: opus-5-5