@actions/cache not restoring cache, version mismatch?

[MSP-Greg]

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 , 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

[MSP-Greg]

Did some more work on this, and I changed the cache key so that it did not match previous keys. Making use of the 'Re-run all jobs' feature.

1. The first job correctly saves the cache

2. The cache key appears in the Web UI's list of caches

3. Re-running the job, the cache is not found, and when trying to save it, the following error logged:

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

[MSP-Greg]

After using the API to get a cache list, and switching core.debug on, it seems the issue is a mismatch in the version of the cache.

From the above the cache key matches, but debug shows:

There exist one or more cache(s) with similar key but they have different version or scope.

[Kurt-von-Laven]

I suspect this may be working as intended on account of cache versioning.

[MSP-Greg]

See #1378 (comment)

[Kurt-von-Laven]

Is passing a copy of the paths a workaround for this issue then?

[MSP-Greg]

Yes. Regardless, one could consider it a breaking change...

[Mater2211]

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 , 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

[eregon]

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

[Kurt-von-Laven]

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

[MSP-Greg]

considering this issue currently has zero upvotes.

Another way of looking at it is whether many 'setup-*' actions were using the current version of @actions/cache.

I looked at several when I opened the PR, almost all were not.

[Weetbix]

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 :)

[jphawk]

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

[oleksandr-danylchenko]

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

[pcfreak30]

Sigh, think I just hit this issue as well...

[ali-kafel]

Running into this issue as well but with github actions self hosted runners in kubernetes mode vs dind mode