Partial match even when only using key

[daxpedda]

I've been using something as simple as:

      - name: Restore Rust
        id: restore
        uses: actions/cache/restore@v3
        with:
          path: ~/.rustup
          key: rust

But for some reason, if the cache doesn't exist, it actually matches on a different key, in this case I've named another cache rustfmt:

2023-04-03T15:07:35.2300547Z ##[group]Run actions/cache/restore@v3
2023-04-03T15:07:35.2300888Z with:
2023-04-03T15:07:35.2301091Z   path: ~/.rustup
2023-04-03T15:07:35.2301275Z   key: rust
2023-04-03T15:07:35.2301523Z   enableCrossOsArchive: false
2023-04-03T15:07:35.2301775Z   fail-on-cache-miss: false
2023-04-03T15:07:35.2301993Z   lookup-only: false
2023-04-03T15:07:35.2302195Z env:
2023-04-03T15:07:35.2302425Z   CARGO_REGISTRIES_CRATES_IO_PROTOCOL: sparse
2023-04-03T15:07:35.2302664Z   CARGO_TERM_COLOR: always
2023-04-03T15:07:35.2302882Z ##[endgroup]
2023-04-03T15:07:36.9535578Z Received 0 of 175967939 (0.0%), 0.0 MBs/sec
2023-04-03T15:07:37.9543626Z Received 88080384 of 175967939 (50.1%), 41.9 MBs/sec
2023-04-03T15:07:38.9676366Z Received 175967939 of 175967939 (100.0%), 55.6 MBs/sec
2023-04-03T15:07:38.9683911Z Cache Size: ~168 MB (175967939 B)
2023-04-03T15:07:38.9973074Z [command]/usr/bin/tar -xf /home/runner/work/_temp/a4330e53-f698-4883-9b37-40e2223e5e9c/cache.tzst -P -C /home/runner/work/despair/despair --use-compress-program unzstd
2023-04-03T15:07:40.1776290Z Cache restored successfully
2023-04-03T15:07:40.5518473Z Cache restored from key: rustfmt

It seems to me that the documentation is pretty clear that key is used for exact matches and restore-keys for partial matches. Furthermore steps.restore.outputs.cache-hit is actually set to true.

Is this a bug, or did I misunderstand the documentation?

[github-actions]

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.

[daxpedda]

This is still relevant.

[samhh]

I'm also seeing this issue with v4.

[dwalintukan]

I encountered this today as well in my Github Action workflow.

Caching step:

- name: Get cached deps
        id: caching
        uses: actions/cache@v4
        with:
          path: |
            deps
            _build
            vendor/**/_build
          key: app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}-${{ hashFiles('**/mix.lock') }}-${{ env.MIX_ENV }}
          restore-keys: |
            app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}-${{ hashFiles('**/mix.lock') }}-${{ env.MIX_ENV }}
            app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}-${{ hashFiles('**/mix.lock') }}
            app-ci-cache-${{ runner.os }}-${{ vars.ELIXIR_VERSION }}-${{ vars.ERLANG_OTP_VERSION }}

Logs for the caching step. Looks like it picked up a cache from a key match.

Run actions/cache@v4
Received 50331648 of 261905428 (19.2%), 48.0 MBs/sec
Received 184549376 of 261905428 (70.5%), 87.9 MBs/sec
Cache Size: ~250 MB (261905428 B)
/usr/bin/tar -xf /home/runner/work/_temp/112d0137-56de-423b-ab50-e509306e7d1c/cache.tzst -P -C /home/runner/work/app/app --use-compress-program unzstd
Received 261905428 of 261905428 (100.0%), 83.1 MBs/sec
Cache restored successfully
Cache restored from key: app-ci-cache-Linux-1.14.5-26.2.3-8f6fd92be06bc44[20]

Then in a downstream setup step:

- name: Install Dependencies and Compile
        if: steps.caching.outputs.cache-hit != 'true'
        run: |
          mix setup

Logs for this setup step. It didn't obey the cache-hit.

Run mix setup
Resolving Hex dependencies...
Resolution completed in 2.769s
Unchanged:
  absinthe 1.6.[8]
  absinthe_plug 1.5.8
  absinthe_relay 1.5.2
  acceptor_pool 1.0.0
  b64fast 0.2.3
  bamboo 2.2.0
  bamboo_phoenix 1.0.0

[DanRStevens]

This looks to be the same issue as was later reported in:

• Wrong Cache restore operation #1433
• Incomplete key restores arbitrary cache object #1385

This comment seems particularly relevant:

• Wrong Cache restore operation #1433 (comment)

I've checked the internal service implementation and it appears that our documentation is incorrect. key uses prefix-matching similar to how restore-keys works.