A missing blob during restore prints downloading blob b9a4c28a839c5c5c: downloading blob b9a4c28a839c5c5c: object not found: downloadNextBlobSet wraps the already-prefixed error from FetchBlob.
A failed shallow verify prints Verification failed: verification failed: 1 blobs have the wrong size: formatVerifyResult wraps errSnapshotVerifyFailed under the command's own prefix.
verify --deep on a file:// destination with a truncated blob prints S3 has 1000 bytes, database has 3420651 bytes (verifyBlobExistenceFromDB).
A purge with an invalid duration prints invalid duration: invalid duration: ...: the purge step adds the prefix the duration parser already put on (noticed while fixing #289).
verify --deep reports any storage error while checking a blob as "blob ... missing from storage" (verifyBlobExistenceFromDB), so a permission or network error is called missing, although the real error is included (noticed while fixing #318).
Definition of done
Each prefix appears once in these messages, and the deep verify message names the destination store, not S3.
Deep verify calls a blob missing only on a not-found answer, and words any other error as a blob it could not check, with the error.
Tests check the five messages.
Model: opus-5-5
Found by the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 (part 3).
**What is wrong:**
- A missing blob during restore prints `downloading blob b9a4c28a839c5c5c: downloading blob b9a4c28a839c5c5c: object not found`: `downloadNextBlobSet` wraps the already-prefixed error from `FetchBlob`.
- A failed shallow verify prints `Verification failed: verification failed: 1 blobs have the wrong size`: `formatVerifyResult` wraps `errSnapshotVerifyFailed` under the command's own prefix.
- `verify --deep` on a `file://` destination with a truncated blob prints `S3 has 1000 bytes, database has 3420651 bytes` (`verifyBlobExistenceFromDB`).
- A purge with an invalid duration prints `invalid duration: invalid duration: ...`: the purge step adds the prefix the duration parser already put on (noticed while fixing https://git.eeqj.de/sneak/vaultik/issues/289).
- `verify --deep` reports any storage error while checking a blob as "blob ... missing from storage" (`verifyBlobExistenceFromDB`), so a permission or network error is called missing, although the real error is included (noticed while fixing https://git.eeqj.de/sneak/vaultik/issues/318).
**Definition of done**
- Each prefix appears once in these messages, and the deep verify message names the destination store, not S3.
- Deep verify calls a blob missing only on a not-found answer, and words any other error as a blob it could not check, with the error.
- Tests check the five messages.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:53:38 +02:00
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.
Found by the defect hunt in #288 (part 3).
What is wrong:
downloading blob b9a4c28a839c5c5c: downloading blob b9a4c28a839c5c5c: object not found:downloadNextBlobSetwraps the already-prefixed error fromFetchBlob.Verification failed: verification failed: 1 blobs have the wrong size:formatVerifyResultwrapserrSnapshotVerifyFailedunder the command's own prefix.verify --deepon afile://destination with a truncated blob printsS3 has 1000 bytes, database has 3420651 bytes(verifyBlobExistenceFromDB).invalid duration: invalid duration: ...: the purge step adds the prefix the duration parser already put on (noticed while fixing #289).verify --deepreports any storage error while checking a blob as "blob ... missing from storage" (verifyBlobExistenceFromDB), so a permission or network error is called missing, although the real error is included (noticed while fixing #318).Definition of done
Model: opus-5-5