Cache consistently misses despite same key, branch, and operating system

[Sainan]

I'm aware of the cache scopes, yet this simple workflow: Causes the cache to consistently miss & create a new cache for each run: This might be because env.EMSDK is some funny volatile value like /home/runner/work/_temp/ea04f67e-177b-46bb-a310-10d3ea9f9115/emsdk-main.

[vinmassaro]

Running into the same issue - working on the default branch, cache is created in one job and attempting to restore in another. Every time, it outputs "Cache not found for input keys" and lists out the attempts, each of which matches the created key.

[Sainan]

Ah yeah I didn't say but "senpai" is my default branch, because "master" was apparently not woke enough.

[allwalte]

According to the docs, the scope of a cache is branch, key, and version, and version "is a way to stamp a cache with metadata of the path and the compression tool used while creating the cache". So if the path is different, then the cache will not hit because the version is different, even if the other two criteria (branch and key) are the same. Given that you do have that "volatile" value as part of your path I'm guessing this is probably what's happening?

If you use the cli command gh api -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" /repos/<OWNER>/<REPO>/actions/caches , you can see info about the caches. In my similar case, I could see two that had the same ref and key, but the version is different (and that's not exposed in the UI when viewing).

[Sainan]

That makes some sense, but is extremely weird behaviour because the path being randomised is literally what happens for each new job run on an actions worker, so I'd still consider this to be an issue.

• The path should be normalised before being used for the algorithm that calculates the version, and/or
• There should be a way to overwrite the version.

Without either of these measures, this workflow step is effectively useless for me.

[allwalte]

I admit this is the first time I've dug into cache behaviour, but...looking, I can see most of our jobs are hitting the cache fine except for the one where we're actually deliberately changing the path after the portion that github creates, which is where it hits the "dup". So it does seem to be working as expected for us. The one difference in what we've got from what you've shown though is that in the path we're using ${{ github.workspace }}/<our path> where you're using env.EMSDK/<your path>, so maybe gh does some magic where it ignores the part of the path that changes as part of the ${{ github.workspace }} var specifically?

[benebene84]

I have a similar issue where I restore a cache - a build artifact from another step - in one workflow step, which works just fine. I need that artifact restored as well in an another workflow step, but this step runs in a docker image, so I can't restore it because keys don't match.

So I assume this is also due to the version. Quite annoying. Would be great to have a possibility to overwrite or disable it.

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 5 days since being marked as stale.

[Sainan]

Would be cool if this issue could actually be resolved and not just closed as resolved. 🙃