Matched signals
- cache is corrupted
- corrupt cache
- invalid cache
- cache hit but install failed
- checksum mismatch
- hash mismatch
- unexpected end of archive
- corrupted tar archive
Corrupted or stale dependency cache
What this failure means
CI restored a dependency cache, but the cached contents were stale, corrupted, or built for an incompatible environment.
Symptoms
Faultline looks for one or more of these log fragments:
cache is corrupted
corrupt cache
invalid cache
cache hit but install failed
checksum mismatch
hash mismatch
unexpected end of archive
corrupted tar archive
Diagnosis
The cache layer existed and restored successfully, but one or more cached artifacts could not be trusted for the current build.
This usually happens after toolchain upgrades, runner OS changes, or partial writes from an interrupted previous job.
Fix steps
- Delete the CI cache entry that backs the failing step and allow it to rebuild from scratch.
- Invalidate the cache by changing the cache key, for example by appending a version suffix or toolchain hash.
- For GitHub Actions, clear the cache via Settings > Actions > Caches.
- If the cache stores platform-specific artifacts, verify the key includes OS, architecture, and toolchain version before restoring it again.
- If the failure is local to one package manager, clear only that tool’s cache rather than wiping the entire home cache directory.
Validation
- Re-run the build from a cold cache.
- Confirm dependency install or linking succeeds without archive or checksum corruption.
Why it matters
A bad cache can fail builds repeatedly and nondeterministically across many branches until someone invalidates it. The broken cache becomes shared build infrastructure rather than a single-job problem.
Prevention
- Include the tool version in the cache key so upgrades invalidate old cache content automatically.
- Validate the cache after restoration with a fast integrity check.
- Set a short cache TTL to prevent caches from becoming permanently stale.
- Avoid caching mutable build outputs that can be partially written when jobs are canceled or retried.
Try it locally
du -sh <cache-dir>
du -sh <cache-dir>
How Faultline detects it
Use faultline explain cache-corruption to see the full playbook.
faultline analyze build.log
faultline explain cache-corruption
Generated from playbooks/bundled/log/build/cache-corruption.yaml. Do not edit directly.