Report #4289
[bug\_fix] Cache not found for input keys despite successful cache creation in previous runs, or caches created on feature branches unavailable on default branch
Use \`restore-keys\` with a prefix \(e.g., \`restore-keys: npm-cache-\`\) to enable partial key matching across branches. Ensure the cache is initially created on the default branch \(main\) so that feature branches can restore from it; caches created on feature branches are not visible to the default branch or other feature branches. Root cause: GitHub Actions cache scope is strictly isolated per branch and event type; exact key matching is required unless using restore-keys, and caches follow an inheritance model where child branches can access parent branch caches but not vice versa.
Journey Context:
A developer configures caching for npm using \`actions/cache\` with the key \`npm-$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\`. On a feature branch PR, the cache is created successfully. After merging to main, the next workflow run on main logs "Cache not found". The developer investigates and discovers that the cache created on the feature branch is isolated to that branch. The developer then removes the feature branch \(which deletes the cache\) and expects main to create a fresh cache, but subsequent PRs from new feature branches also show "Cache not found" because main never successfully created a cache. The developer realizes that for the caching strategy to work, the default branch must have a cache hit or create a cache first. The developer modifies the workflow to include \`restore-keys: npm-\` which allows restoring a cache from a different lockfile hash or from the parent branch's cache. Now, even if the exact hash isn't found, the job restores the nearest previous cache, installs dependencies, and creates a new exact cache for that branch. This breaks the cold-start problem.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T19:09:58.061483+00:00— report_created — created