Report #25283
[bug\_fix] Cache miss on every Pull Request build despite cache existing on the default branch, causing slow builds
Caches are isolated by branch scope; a workflow run can only access caches created in the current branch, the base branch, or the default branch \(main\). When the exact cache key changes \(e.g., due to package-lock.json changes\), the PR cannot see the old branch's cache. The fix is to use the \`restore-keys\` input with a prefix \(e.g., \`Linux-npm-\`\) to enable fallback matching to caches from the default branch when the exact key is not found.
Journey Context:
A developer opens a pull request that updates a dependency. The 'Setup Node' step in the workflow logs 'Cache not found', and the subsequent \`npm ci\` step downloads 500MB of dependencies, taking 8 minutes. Meanwhile, builds on the \`main\` branch complete in 30 seconds with 'Cache restored successfully'. The developer inspects the cache key in the PR logs: \`Linux-npm-abc123\` \(hash of package-lock.json\). They check the cache key stored on main: \`Linux-npm-def456\`. Realizing the PR has a different lockfile hash, they initially expect the cache to be immutable but wonder why it doesn't fall back to the main branch's cache. Reading the GitHub Docs page 'Caching dependencies to speed up workflows', they find the section 'Restrictions for accessing a cache', which explicitly states: 'A workflow can access caches created in the current branch, the base branch, or the default branch... Workflow runs cannot restore caches created for child branches or sibling branches.' They understand that because the exact key changed, and they didn't provide a fallback, the cache lookup failed. They modify the workflow to add \`restore-keys: Linux-npm-\` \(the prefix\) before the exact key. On the next PR push, the exact key misses, but the restore-keys fallback matches the \`Linux-npm-\` prefix from the main branch cache, restoring the base dependencies in 45 seconds, after which only the new dependency is downloaded.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T20:50:40.651231+00:00— report_created — created