toolkit: @actions/cache not restoring cache, version mismatch?

It’s quite disappointing such a clear and important issue with an attached PR is not dealt with in a month, GitHub Actions maintainers.

This is now affecting bahmutov/npm-install and affected us through a dependabot bump of that action, and then it takes some time to notice the install time in CI has exploded. So I expect soon some more thumbs 😃

Same here, bahmutov/npm-install started to fail with npm cache hit undefined.

I’m getting the npm cache hit undefined using bahmutov/npm-install. But the error at the end of the job says: “Cache already exists”.

Run bahmutov/npm-install@v1
running npm-install GitHub Action
trying to restore cached NPM modules
npm cache hit undefined
installing NPM dependencies using Yarn
yarn at "/usr/local/bin/yarn"
/usr/local/bin/yarn --frozen-lockfile
yarn install v1.22.1[9](https://github.com/soomo/soomo-libs/actions/runs/5113056605/jobs/9191825213#step:4:10)
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 91.81s.
saving NPM modules
/usr/bin/tar --posix -cf cache.tgz --exclude cache.tgz -P -C /home/runner/work/soomo-libs/soomo-libs --files-from manifest.txt -z
Failed to save: Unable to reserve cache with key yarn-linux-x64-65564ad27734da79a8bf93c83f3cc52e2c9092a2bcc4055cb585189ce0ad818991d96191d7ee8c26b059c2bf77761e9556ac177d550de0fce0d72a7f5496013b, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/optimize-deps-caching, Key: yarn-linux-x64-65564ad27734da79a8bf93c83f3cc52e2c9092a2bcc4055cb585189ce0ad818991d96191d7ee8c26b059c2bf77761e9556ac177d550de0fce0d72a7f5496013b, Version: 0c41bf16438f4e14c90cefc5b0bdf3ec0117ae5259e0aba7b672a985e7dd5[46](https://github.com/soomo/soomo-libs/actions/runs/5113056605/jobs/9191825213#step:4:47)d
all done, exiting

Describe the bug

We use @actions/cache in a popular setup action. Recently updated the lock file which previously used 3.0.6 without issue. Caches appear to be saved, but they are not restored with restoreCache.

In the first job run, often the cache was saved. If the next run did not restore it, the run also had the common error:

‘Failed to save: Unable to reserve cache with key <key>, another job may be creating this cache. More details: Cache already exists.’

But, inspecting all the keys, the key of the saved cache from the previous job run is the same as the key it cannot find in the 2nd job run. See https://github.com/MSP-Greg/puma/actions/runs/4452716291/jobs/7820684254#step:3:121

As to versions, first, we updated to current (3.1.2). That did not work with code that worked with 3.0.6. Investigated further:

                     1st Job Run               2nd Job Run
@actions/cache  Ubuntu  macOS  Windows    Ubuntu  macOS  Windows
      3.0.6       ✅     ✅      ✅        ✅     ✅      ✅
      3.1.0       ✅     ✅      ❌        ✅     ✅      ✅
      3.1.1       ❌     ❌      ❌        ✅     ✅      ✅
      3.1.2       ❌     ❌      ❌        ❌     ❌      ❌
      3.1.4       ❌     ❌      ❌        ❌     ❌      ❌

As noted above, version 3.1.2 and later never restores a cache. 3.1.1 did not restore a cache on the first, run but did on the second run.

To Reproduce Steps to reproduce the behavior: See https://github.com/MSP-Greg/puma/actions/workflows/actions-cache.yaml. Each run in Puma was done with a corresponding branch in https://github.com/MSP-Greg/setup-ruby that was built with the given @actions/cache version.

Expected behavior Versions after 3.0.6 restore caches.

Screenshots NA

Desktop (please complete the following information): NA

Sigh, think I just hit this issue as well…

I don’t think that’s particularly fair considering this issue currently has zero upvotes.

See https://github.com/actions/toolkit/pull/1378#issuecomment-1478388929