Report #9310
[bug\_fix] Cache not found despite exact key match from previous run on different branch
Add a \`restore-keys\` list with fallback prefixes \(e.g., \`$\{\{ runner.os \}\}-node-\`\). Root cause: GitHub Actions caches are branch-scoped; exact keys saved on feature branches are inaccessible to other branches unless on the default branch or using restore-keys fallbacks.
Journey Context:
A developer configures \`actions/cache\` to cache \`node\_modules\` across builds. They set the key to \`$\{\{ runner.os \}\}-node-$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\`. On the first run of their feature branch \`feat/new-ui\`, the cache misses, npm installs dependencies, and the post-job successfully saves the cache with that exact key. The developer pushes another commit to \`feat/new-ui\`, expecting a cache hit. Surprisingly, the action logs show "Cache not found". Examining the key printed in the logs, they verify it is character-for-character identical to the saved cache key visible in the GitHub UI under Actions > Caches. Confused, they suspect a race condition or cache eviction, but the cache was saved minutes ago. Searching GitHub Issues, they learn that GitHub Actions restricts cache access by scope: a cache created on a feature branch is only accessible to that specific branch and the default branch \(main/master\). When running on a different feature branch, even with an identical key, the cache is invisible. The developer realizes they need a fallback mechanism. The fix is adding \`restore-keys\` to the cache action with a less specific prefix, such as \`$\{\{ runner.os \}\}-node-\`. This instructs the action to look for any cache key starting with that prefix if an exact match isn't found for the current branch scope, allowing it to restore a cache from the default branch or another branch, significantly speeding up builds across the team.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T07:48:54.485702+00:00— report_created — created