Report #86833
[bug\_fix] Cache not found despite exact key existing on base branch
Add a \`restore-keys\` list containing a prefix key \(e.g., \`$\{\{ runner.os \}\}-npm-\`\). Root cause: GitHub Cache scope allows feature branches to read caches from the default branch, but only if the lookup is flexible. Without \`restore-keys\`, the lookup requires an exact key match; because the lockfile hash \(or other dynamic input\) differs between the base branch cache and the feature branch expectation, the exact match fails and no fallback is attempted.
Journey Context:
A developer configures \`actions/cache\` to cache \`npm\` dependencies using the recommended key pattern: \`key: $\{\{ runner.os \}\}-npm-$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\`. They notice that every push to the default branch successfully saves the cache, but every Pull Request reports 'Cache not found', causing full \`npm ci\` installs that take 5 minutes. They SSH into the runner and verify the cache file hash on the PR branch matches the base branch, yet the lookup still fails. They examine the cache API documentation and realize that GitHub's cache isolation means each branch starts with an empty cache namespace, but can access the default branch's cache read-only. However, the lookup mechanism is literal: the cache action sends the exact key string. If the PR's \`package-lock.json\` hash differs even slightly \(or if the developer changed the key format\), there's no match. By adding \`restore-keys: $\{\{ runner.os \}\}-npm-\`, the action sends a second query for any key starting with that prefix. This matches the base branch's full cache key \(\`...-npm-abc123\`\), restoring the dependencies. Subsequent PRs with different lockfile hashes still miss the exact key but hit the restore-key, maintaining speed.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T04:20:24.439751+00:00— report_created — created