Skip to content

fix(cache): invalidate cache written by a different binary version#51

Merged
subinium merged 1 commit into
mainfrom
fix/cache-binary-version-invalidation
Jun 11, 2026
Merged

fix(cache): invalidate cache written by a different binary version#51
subinium merged 1 commit into
mainfrom
fix/cache-binary-version-invalidation

Conversation

@subinium

Copy link
Copy Markdown
Owner

Problem

load_cache invalidates only on CACHE_VERSION mismatch or data-source mtime advance. When scanner SQL/parsing logic changes inside the same CACHE_VERSION, an upgraded binary keeps serving per-session payloads written by the old binary until the data source's mtime happens to move — the "data didn't change but its interpretation did" failure mode described in #37 (option A there).

Fix

  • CacheFile gains agf_version: String (stamped with env!("CARGO_PKG_VERSION") on write, #[serde(default)] on read so pre-field caches parse and then fail the match).
  • Validation is extracted into a pure parse_cache(content, binary_version) -> Result<CacheFile, String> checking parse → schema version → binary version, in that order.
  • load_cache rescans on any rejection; AGF_DEBUG=1 logs the reason, e.g. cache built by 0.11.4, current 0.12.0 → rescanning.
  • The write_cache carry-over path for in-flight agents goes through the same gate, so entries shaped by an older binary are dropped rather than re-persisted with a fresh mtime.
  • CACHE_VERSION stays for schema changes within one package version (dev builds); the header comment documents the relaxed bump policy.

Cost: one full rescan per upgrade (a few hundred ms) — the trade-off recommended in the issue.

Tests

parse_cache unit tests: accept on full match; reject on schema mismatch, binary mismatch, missing agf_version (legacy cache), and unparseable content. cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test (58/58) all pass.

Closes #37

🤖 Generated with Claude Code

mtime freshness can't detect scanner-logic changes that ship without a
CACHE_VERSION bump: the source data didn't change, but the binary's
interpretation of it did (#37). Stamp CARGO_PKG_VERSION into the cache
file and treat any mismatch as stale on load, at the cost of one full
rescan per upgrade. The write-side carry-over path for in-flight agents
is gated the same way so entries shaped by an older binary are dropped
instead of being re-persisted with a fresh mtime.

Validation now lives in a pure parse_cache helper; AGF_DEBUG=1 logs
which binary wrote the rejected cache ("cache built by X, current Y").

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@subinium subinium mentioned this pull request Jun 11, 2026
@subinium subinium merged commit 4251d82 into main Jun 11, 2026
5 checks passed
@subinium subinium mentioned this pull request Jun 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cache: stale check misses scanner-logic changes within the same CACHE_VERSION

1 participant