actions/cache version mismatch, cache not restored in CI

By Daniel Zoghalchali·Latchkey

Every actions/cache entry has an internal "version" computed from the path list and the compression method. If you change the cached paths or the runner's tar/zstd setup, the version no longer matches the saved entry, so the same key restores nothing even though it exists.

What this error means

A key that previously restored now misses ("Cache not found for input keys") after the path was edited or the compression tool changed, even though the saved cache is visible in the cache list.

Cache not found for input keys: deps-Linux-abc123
# the key exists, but its stored version (path+compression) differs from this run's

Common causes

The cached path list changed

Adding, removing, or reordering entries in path changes the computed cache version, so the old saved entry no longer matches the new lookup.

The compression method differs across runners

A runner missing zstd falls back to gzip; the differing compression yields a different version that will not match an entry saved with the other method.

How to fix it

Keep the path list stable, and re-save under the new version

1. Hold the path list constant once a cache is established.
2. If you must change paths, bump the key prefix so a fresh entry is created.
3. Let one run save under the new version, then later runs restore it.

# bump the prefix when the path set changes
key: deps-v2-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}

Ensure consistent compression across runners

Use the same runner images so zstd is consistently available; an environment without zstd silently changes the cache version and breaks restores.

How to prevent it

• Treat the path list as part of the cache identity; keep it stable.
• Bump the key prefix whenever paths change.
• Use consistent runner images so compression stays the same.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions