Report #13140
[bug\_fix] "Cache not found" during \`actions/cache\` restore step despite the cache being visible in the repository's "Actions > Caches" UI with an identical key
Use \`restore-keys\` with a prefix fallback \(e.g., \`node-modules-Linux-\`\) to match caches from the default branch, or ensure the cache is saved on the default branch \(\`main\`\) via a \`push\` or \`schedule\` trigger so it is available as a fallback for PRs.
Journey Context:
Developer sets up \`actions/cache\` to cache \`node\_modules\` in a CI workflow. They push to a feature branch, the cache is saved successfully with key \`node-modules-Linux-npm-abc123\`. They open a Pull Request. The workflow runs again on the PR event, but the step shows "Cache not found". Developer verifies the key is identical, checks the Actions tab and sees the cache exists in the "Caches" management section, yet it's not restored. They suspect a bug in the cache action. After digging through community discussions, they learn about cache isolation: caches saved from \`push\` events on feature branches are not accessible to \`pull\_request\` events targeting the default branch, and vice versa, to prevent cache poisoning from untrusted code. The "aha" moment occurs when they realize they need to ensure the cache is populated on the default branch \(main\) via a \`push\` to \`main\`, or use a restore key that falls back to the main branch cache. They modify the workflow to trigger on \`push\` to \`main\`, ensuring the cache is saved there, and update the restore-keys to include \`node-modules-Linux-npm-\` as a prefix. Now PRs can restore from the main branch cache. The fix works because \`restore-keys\` enables partial matching across branch boundaries, while explicit cache hits are scoped to the branch/event type for security.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T17:50:28.087627+00:00— report_created — created