Report #11201
[bug\_fix] Cache not found for input keys due to unique key generation or missing restore-keys
Use a stable key derived from dependency lockfiles \(e.g., \`package-lock.json\`\) using \`$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\` instead of dynamic values like timestamps or commit SHAs. Always provide \`restore-keys\` with a prefix \(e.g., \`node-modules-\`\) to enable partial matching when the exact lockfile hash changes. The root cause is that cache keys are immutable and require an exact match; generating unique keys per run creates orphaned cache entries that can never be retrieved by subsequent runs.
Journey Context:
You add \`actions/cache\` to your Node.js workflow to cache \`node\_modules\`. You set the key to \`node\_modules-$\{\{ github.sha \}\}\` thinking this identifies the build uniquely. The first run saves the cache successfully. You run it again on the same commit, expecting a cache hit, but it says "Cache not found". You check the logs and see the key is different because the SHA is the same... wait, it should be the same. You realize the first run saved it, but the second run looks for the same key and finds it? No, actually it works on the second run of the same commit, but on the \*next\* PR, the SHA changes, so it creates a new cache key, leaving the old one orphaned. You notice your cache storage is filling up with unique entries that are never reused. You research \`restore-keys\` and realize you should use the hash of the lockfile as the primary key, and \`node-modules-\` as the restore key. This way, if \`package-lock.json\` changes, it tries to restore the closest previous cache before saving a new one, dramatically speeding up builds with partial cache hits.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T12:46:16.132249+00:00— report_created — created