Repository navigation
session cache entries carry no build/schema fence — foreign-build caches mix silently #1095
Description
From vidoluco's #946 validation postmortem: their unpublished local build wrote synthetic calls into a shared cache dir; the published build read them back and served them (cost double-counted, 1.83x) because session-cache.v9 entries are fingerprinted on the SOURCE FILE only, with no record of the build/semantics that produced them. Two builds with different cost semantics sharing CODEBURN_CACHE_DIR mix silently and keep matching on fingerprint. Their words: 'a build or schema fence would have turned three days of hunting into a cache miss.' Fix idea: stamp entries (or the envelope) with a semantics token (e.g. the PROVIDER_PARSE_VERSIONS hash already exists — but their build shared it; consider a build-id or an explicit cache-semantics version distinct from parse versions) and treat mismatch as a cache miss for that provider.
Activity
iamtoruk commentedon Aug 22, 2026
Maintainer decision: not CodeBurn's problem. The incident that motivated this (an unpublished local build sharing the official cache dir with the released binary) is experimenter responsibility, not a product defect — the released build's math is correct for caches the released build wrote. An attempted fence (PR #1103) was reviewed and closed: it could not have caught the actual incident (a fork sharing version constants hashes identically; pre-fence writers strip any token on every write) and it regressed per-provider invalidation into global cache wipes. Guidance for contributors: run experimental builds with their own CODEBURN_CACHE_DIR. Reopen only if a mechanism exists that catches foreign builds without cost to release users.