🐛 - partial match downloads incompatible cache file

[jromero-pg]

Describe the bug

We use similar steps (and there by caching logic) across multiple jobs that run on different runners. There's an issue with the current version of @actions/cache this action is using that fails to detect zstd properly. The side effect from that bug is that cache is packages using zstd but later downloaded with an attempt to unpackage is using tar (gzipped).

Looking at the code base, this is due to findObject using the key without including cacheFilename. Whereas save creates the object using key + cacheFilename. This effectively makes restore a partial match instead of an exact match.

To Reproduce

1. Upload a file to s3 bucket named some-file/cache.invalid-ext

2. Create a workflow:

   name: dev ci
   
   on:
     push:
   
   jobs:
     build_test:
       runs-on: [ubuntu-latest]
   
       steps:
         - uses: tespkg/actions-cache@v1
           with:
             accessKey: <KEY>
             secretKey: <SECRET>
             bucket: actions-cache
             key: some-file
             path: |
               some-file

Notice that some-file/cache.invalid-ext is downloaded.

Expected behavior

some-file/cache.invalid-ext should not match.

Screenshots

Downloading cache from s3 to /home/runner/work/_temp/40beba19-4ba0-481f-b3b5-e0e15a77898b/cache.tgz. bucket: [redacted], object: yarn_cache/Linux/node-v18.14.0/node_modules/78a1371352bc39bad3648657a648efb16cc6b2ddd32c9f211676347fe3fa3bc2/cache.tzst
Cache Size: 534.57MB (534565386 bytes)
/usr/bin/tar -z -xf /home/runner/work/_temp/40beba19-4ba0-481f-b3b5-e0e15a77898b/cache.tgz -P -C /home/runner/work/paragon/paragon

gzip: stdin: not in gzip format
/usr/bin/tar: Child returned status 1
/usr/bin/tar: Error is not recoverable: exiting now
Restore s3 cache failed: Tar failed with error: The process '/usr/bin/tar' failed with exit code 2
Restore cache using fallback cache
Fallback cache restore failed

Code/Script reproduction

Additional context

[jackieli-tes]

Hi @jromero-pg , this all make sense. Are you willing to submit a quick fix for this? Feels pretty straight forward?

[jromero-pg]

Unfortunately, we only stumbled upon migrating across different runners, and I've been heads down trying to make that happen.

I agree that it's pretty straightforward. Maybe it's worth adding a good-first-issue label? :)

[jackieli-tes]

@jromero-pg I remember encountering this during the initial dev. I resolved it by using utils.getCompressionMethod(); from "@actions/cache/lib/internal/cacheUtils"; see https://github.com/tespkg/actions-cache/blob/main/src/save.ts#L38

If it only happens during runner migration, I don't think we should pay special attention to it: It should to restore cache and save a new one.

I'll close this one, but feel free to re-open if this is not the case

[gstoehld]

We ran into this exact issue. The problem is that the new cache is never saved: Cache was exact key match, not saving