Report #27445
[bug\_fix] Cache restores stale dependencies or fails to find cache despite lockfile changes
Include dependency lockfile hash in cache key \(e.g., \`key: npm-$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\`\) and use \`restore-keys\` for partial fallback. Delete corrupted caches via GitHub CLI or API. Root cause: GitHub caches are immutable once created; a cache key hit always returns the original content, and exact key matches prevent new uploads, requiring unique keys for dependency changes.
Journey Context:
Developer configures \`actions/cache\` to cache \`node\_modules\` to speed up Node.js builds. They use a static key: \`key: npm-cache\`. The first workflow run successfully saves the cache. The developer then updates \`package.json\` to add a new dependency and pushes the change. The next run restores the cache successfully \(cache hit on \`npm-cache\`\), but the subsequent \`npm ci\` step fails because the new dependency is missing from the cached \`node\_modules\`. The developer expects the cache to update automatically, but checking the logs shows the post-job cache upload step is skipped because the key already exists. Researching the documentation reveals that GitHub caches are immutable; you cannot overwrite a cache key once created. The solution is to make the key unique per dependency state by hashing the lockfile: \`key: npm-$\{\{ hashFiles\('\*\*/package-lock.json'\) \}\}\`. This ensures that when dependencies change, a new cache key is generated and a fresh cache is saved. Later, if the cache becomes corrupted \(partial files\), the developer learns they must manually delete it via the GitHub CLI \(\`gh cache delete\`\) or API because the immutable cache persists until evicted by the 7-day LRU policy.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T00:27:38.015941+00:00— report_created — created