What is wrong:RunDeepVerify (internal/vaultik/verify.go) sets verified only on success and never sets missing. With one of two blobs deleted, --deep --json gives "verified": 0, "missing": 0 (shallow --json gives "verified": 1, "missing": 1). With bytes flipped in one of two blobs it gives "verified": 0, although the text run reports "Verified 1/2 blobs" before failing.
Definition of done
Under --deep --json the counts say how many blobs were checked and passed, and how many were missing, as in shallow mode, on success and on failure.
Tests cover a missing blob and a damaged blob.
Model: opus-5-5
Found by the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 (part 1).
**What is wrong:** `RunDeepVerify` (`internal/vaultik/verify.go`) sets `verified` only on success and never sets `missing`. With one of two blobs deleted, `--deep --json` gives `"verified": 0, "missing": 0` (shallow `--json` gives `"verified": 1, "missing": 1`). With bytes flipped in one of two blobs it gives `"verified": 0`, although the text run reports "Verified 1/2 blobs" before failing.
**Definition of done**
- Under `--deep --json` the counts say how many blobs were checked and passed, and how many were missing, as in shallow mode, on success and on failure.
- Tests cover a missing blob and a damaged blob.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:47:16 +02:00
Fixed in #362: under --deep --json, verified now counts the blobs whose contents passed before any failure, and missing (with missing_size and mismatched) counts every blob absent from storage or stored with the wrong size. Deep verify still stops at the first damaged blob and reads no contents while blobs are missing, so verified is 0 in that case.
Model: opus-5-5
Fixed in https://git.eeqj.de/sneak/vaultik/pulls/362: under `--deep --json`, `verified` now counts the blobs whose contents passed before any failure, and `missing` (with `missing_size` and `mismatched`) counts every blob absent from storage or stored with the wrong size. Deep verify still stops at the first damaged blob and reads no contents while blobs are missing, so `verified` is 0 in that case.
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.
Found by the defect hunt in #288 (part 1).
What is wrong:
RunDeepVerify(internal/vaultik/verify.go) setsverifiedonly on success and never setsmissing. With one of two blobs deleted,--deep --jsongives"verified": 0, "missing": 0(shallow--jsongives"verified": 1, "missing": 1). With bytes flipped in one of two blobs it gives"verified": 0, although the text run reports "Verified 1/2 blobs" before failing.Definition of done
--deep --jsonthe counts say how many blobs were checked and passed, and how many were missing, as in shallow mode, on success and on failure.Model: opus-5-5
Fixed in #362: under
--deep --json,verifiednow counts the blobs whose contents passed before any failure, andmissing(withmissing_sizeandmismatched) counts every blob absent from storage or stored with the wrong size. Deep verify still stops at the first damaged blob and reads no contents while blobs are missing, soverifiedis 0 in that case.Model: opus-5-5