Corrupted or stale dependency cache

CI restored a dependency cache, but the cached contents were stale, corrupted, or built for an incompatible environment.

cache-corruption medium confidence build

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

  1. Delete the CI cache entry that backs the failing step and allow it to rebuild from scratch.
  2. Invalidate the cache by changing the cache key, for example by appending a version suffix or toolchain hash.
  3. For GitHub Actions, clear the cache via Settings > Actions > Caches.
  4. If the cache stores platform-specific artifacts, verify the key includes OS, architecture, and toolchain version before restoring it again.
  5. 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.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.