Report #66690
[bug\_fix] actions/cache restore fails on feature branch despite cache existing on main
Add \`restore-keys\` with a prefix fallback \(e.g., \`restore-keys: npm-cache-\`\) to the cache action. Root cause: GitHub Actions cache is immutable and scoped to a combination of the cache key, the workflow ref \(branch\), and repository. A cache created on the \`main\` branch is not accessible on a \`feature\` branch unless using a fallback key that matches only the prefix, allowing cross-branch cache inheritance.
Journey Context:
You set up a workflow to cache \`node\_modules\` using \`actions/cache\` with the key \`npm-cache-$\{\{ hashFiles\('package-lock.json'\) \}\}\`. On the \`main\` branch, it works perfectly—cache hits and restores in seconds. You open a PR from a feature branch, and suddenly the 'Restore cache' step reports 'Cache not found for input keys'. You check the exact key in the logs—it matches the one on main exactly. You re-run the main branch workflow—it finds the cache instantly. You inspect the cache tab in the Actions UI and see the cache entry exists but is scoped to the 'main' branch. Searching 'github actions cache not found feature branch' reveals documentation explaining that caches are scoped to the branch \(ref\) and immutable. The 'aha' moment comes when realizing \`restore-keys\` is not just for partial key matching but specifically designed for cross-branch cache inheritance. You modify the workflow to include \`restore-keys: npm-cache-\` as a fallback. On the next feature branch run, it fails to find the exact key, falls back to the prefix key, finds the main branch's cache, and restores it, cutting the build time from 5 minutes to 30 seconds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T18:24:58.661159+00:00— report_created — created