Fix every finding surfaced by the canonical .golangci.yml with
golangci-lint v2.12.2 (refs #61), behavior-preserving throughout:
- err113: dynamic errors replaced with package-level sentinels and %w
wrapping; direct comparisons converted to errors.Is
- goprintffuncname: printf-style helpers renamed with an f suffix
(ui.Writer message methods, cli.ReportErrorf, database.Fatalf,
vaultik stdoutf) and all call sites updated
- revive: stuttering type names renamed (blob.Handler, blob.WithReader,
blob.ChunkPosition, storage.URL, storage.Info), doc comments added,
unused parameters blanked, package comments added
- contextcheck/noctx: ctx threaded through blob.Packer
(AddChunk/Flush/FinalizeBlob/PackChunks) and scanner call sites;
context-aware exec and sql variants used
- funlen/cyclop/gocognit/nestif/dupl: oversized or duplicated
functions split into focused helpers across production and test code
- paralleltest/tparallel/thelper/usetesting/testpackage: tests
parallelized where safe (global log.Initialize kept in the serial
phase), helpers marked, t.TempDir adopted, external test packages
where only exported API is used
- gosec: integer conversions clamped or justified, header timeouts
added, remaining findings suppressed with per-site justifications
- mnd/goconst/lll/wsl_v5/nlreturn/noinlineerr/errcheck and other
mechanical findings fixed directly
Remove the deprecated log.LogOptions alias (callers migrated to
log.Options). make check is green.
Captures three behaviors the restore hot path must exhibit but
currently doesn't, all under one test:
* Peak blob disk cache occupancy ≤ 1. Smart restore ordering should
drain every file referencing the currently-cached blob before
downloading the next one, so the sweeper can free each blob the
moment its file set is exhausted.
* Every remote blob fetched exactly once (counter on a wrapping
Storer). Already true today; the test pins it so neither future
cache-eviction nor reorder regressions can introduce
re-downloads.
* blobDiskCache.Get is never called during restore — chunk
extraction must go through ReadAt so we never read the whole
blob from disk to slice out a few KB. The 10 GB
photo-snapshot --debug output showed ~900 ms per cache-hit chunk
extract; ReadAt should bring that to sub-millisecond.
Adds Get/ReadAt call counters and a peak-Len tracker to
blobDiskCache, plus an internal restoreCacheObserver hook on Vaultik
so the test can capture the production cache instance without
exporting unexported types.
Currently fails with peak_len=3, get_calls=24, readat_calls=0. The
fix follows in subsequent commits.
