Report #7981
[bug\_fix] Cache not found or cache misses when the same key exists on a different branch
Understand that GitHub Actions caches are branch-scoped: a cache created on a feature branch is only accessible to that specific branch and its descendants, not to other feature branches or the default branch \(except that any branch can access caches from the default branch\). To handle this, use \`restore-keys\` with fallback patterns \(e.g., primary key \`npm-$\{\{ runner.os \}\}-$\{\{ hashFiles\('package-lock.json'\) \}\}\` with restore-key \`npm-$\{\{ runner.os \}\}-\`\). Ensure your CI creates a cache on the default branch first so feature branches can inherit it. Root cause: GitHub's cache isolation model prevents cache poisoning between branches by restricting cache visibility to the branch of creation and the default branch.
Journey Context:
You implement dependency caching for your Node.js project using \`actions/cache\`. You test it on the main branch: the first run creates a cache, subsequent runs restore it in seconds. You open a feature branch to add a new feature, push it, and the workflow runs but the cache step reports 'Cache not found'. You check the exact cache key in the logs \(\`npm-Linux-abc123...\`\) and verify via the GitHub CLI that this exact key exists on the main branch. You try re-running the workflow, still no hit. You search documentation and discover the branch scope restriction: caches created on feature branches are isolated to that branch, and while feature branches can read from the default branch, they cannot read from other feature branches. Since you only just created this feature branch, it has no cache of its own, and if the default branch's cache is outdated \(different lockfile hash\), you get a miss. The fix is implementing \`restore-keys\` with a prefix pattern \(\`npm-Linux-\`\) so that even if the exact hash doesn't match, it falls back to the most recent npm cache from the default branch, and ensuring that your default branch regularly updates its cache so feature branches have a recent fallback.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T04:15:33.454677+00:00— report_created — created