Shared Key not being respected

[abdulrabbani00]

Right now I have this config run whenever we have a merge to main:

- name: Update Rust cache
        uses: Swatinem/rust-cache@v2
        with:
          prefix-key: "v0"
          shared-key: "main"
          save-if: "true"
          cache-on-failure: true

When in my PR branches (base branches) I have the following:

      - name: Setup Rust caching
        if: steps.check_rust_changes.outputs.has_rust_changes == 'true'
        uses: Swatinem/rust-cache@v2
        with:
          prefix-key: "v0"
          shared-key: "main"
          save-if: "false"

For some reason my base branches search for: Warning: Cache not found for keys: v0-main-Linux-x64-5f2382c3-c8b779c5, v0-main-Linux-x64-5f2382c3

So I can find the cache on my main branch but not on subsequent PR branches (base branches). I would expect this functionality to search for the cache v0-main.

Can someone help me understand this if I am misunderstanding?

[nyetwurk]

The source code in config.ts v2.7.8 has a critical bug in how shared-key affects cache restoration. Here's what's happening:

1. When shared-key is set, the cache key is constructed as:

   {prefix-key}-{shared-key}-{auto-os}-{auto-arch}-{env-hash}-{lock-hash}
   

2. But the restoreKey is constructed as:

   {prefix-key}-{auto-os}-{shared-key}
   

This creates a mismatch because the shared-key appears before {auto-os} in the cache key but it appears after {auto-os} in the restoreKey

As a result:

• The restoreKey will never match any cache keys
• Partial matching is effectively disabled when using shared-key
• The only way to restore a cache would be with an exact key match, which is unlikely due to environment and lock hashes changing frequently

Without shared-key, partial matching works correctly:

• Cache key: {prefix-key}-{key}-{auto-os}-{auto-arch}-{env-hash}-{lock-hash}
• RestoreKey: {prefix-key}-{auto-os}
• Will match any cache key starting with {prefix-key}-{auto-os}

Don't use shared-key. It's hopelessly broken.

[abdulrabbani00]

@Swatinem - Any chances this is going to get fixed, IMO this is a critical bug in this package.

[Swatinem]

can you point me to any bug that exists directly?
re-reading the code, I don’t think there is any issue with it.

[nyetwurk]

it is in 2.7.8 (which is the latest release)

the latest main/HEAD is dramatically different, which means on the next release everyone will likely have to change their config, there might be breaking changes.

[Swatinem]

Yes, and that code looks to be correct. There is no way that parts of the key are suddenly flipped around.

[nyetwurk]

It could be I misread it. It definitely wasn't working for me. I'll check again