Actions cache not restoring between runs even though key matches

[nextyze-lgtm]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Code Search and Navigation

Body

I've got a workflow using actions/cache to cache node_modules, and it worked fine for weeks. Now it just doesn't seem to be restoring anymore, every run says "Cache not found for input keys" even though I can see a cache with a matching key in the repo's Actions cache list.

Nothing changed in the workflow file, same key format, same paths. Only thing that's different is we merged in a few PRs that touched the lockfile, so the key hash would've changed at some point, but it should just create a new cache entry, not break restoring on subsequent runs.

For anyone who's run into this:

Does the 10GB per-repo cache limit cause older caches to get silently evicted, and would that explain intermittent misses?
Do caches expire after a certain period of no access, even if under the size limit?
Is there a reliable way to confirm whether a cache actually got saved at the end of a run, versus the save step silently failing?

Trying to figure out if this is an eviction issue or if my save step is quietly not working.

[Bluenovers]

Yeah, this lines up with a few known cache behaviors:

Caches do get evicted once the repo hits the 10GB total limit, oldest unused ones first, so if you've got a bunch of caches piling up from different branches/PRs, older node_modules caches can get bumped even if your specific key still shows up in the list UI (that list can lag behind actual eviction).
Caches also expire after 7 days of no access, so if a branch went quiet for a while and nobody's builds hit that key, it's gone even though nothing look wrong on your end.
On the "did save actually work" question, check the raw logs for the cache step specifically, if there's a warning like "Cache save failed" or "Skipping cache due to key already existing" it'll be in there but easy to miss since it usually doesn't fail the whole job. A green checkmark on the job doesn't guarantee the save step succeeded.
One common gotcha: if the same key already exists from an earlier run in the same workflow, the save step silently no-ops instead of overwriting, so if your lockfile-based key stayed the same across a couple runs for unrelated reasons, only the first run's save actually sticks.

I'd start by grepping the logs for the cache action's save/restore lines directly rather than trusting the summary, that usually tells you immediately whether it's an eviction issue or a silent save failure.