[BUG] restore-prefixes-first-match still triggers when primary key matches

[kristoff3r]

Describe the bug

I use the action like this:

      - name: Restore and cache Nix store
        uses: nix-community/cache-nix-action@v5
        with:
          primary-key: nix-${{ runner.os }}-${{ hashFiles('./flake.nix', './flake.lock') }}-${{ hashFiles('./src/**/*.nix')}}
          restore-prefixes-first-match: nix-${{ runner.os }}-${{ hashFiles('./flake.nix', './flake.lock') }}
          gc-max-store-size-linux: 1073741824
          purge: true
          purge-prefixes: nix-${{ runner.os }}-
          purge-created: 0
          purge-primary-key: never

The idea is that it would try to find an exact cache, and then fallback to one with the same flake/lock otherwise. But even when it hits a primary key it still tries to restore from prefixes, resulting in the same cache being restored twice:

Run nix-community/cache-nix-action@v5

Searching for a cache with the key "nix-Linux-5d8aa1663a7b1fa3908160613db3082990513dc6f220490f58e278604f59ab79-880ef0004b92be6813dd054d992a06382d688d9bd2cf3cc7c8201dc7ab670084".
Lookup only - skipping download
Found a cache with the given "primary-key".
Copying "/nix/var/nix/db/db.sqlite" to "/home/runner/work/_temp/bb6847dc-b1e6-43e8-a639-9a6fa9e284df/old.sqlite".
Restoring a cache with the key "nix-Linux-5d8aa1663a7b1fa3908160613db3082990513dc6f220490f58e278604f59ab79-880ef0004b92be6813dd054d992a06382d688d9bd2cf3cc7c8201dc7ab670084".
Logs produced while restoring a cache.
Finished restoring the cache.
Copying "/nix/var/nix/db/db.sqlite" to "/home/runner/work/_temp/bb6847dc-b1e6-43e8-a639-9a6fa9e284df/new.sqlite".
Merging store databases "/home/runner/work/_temp/bb6847dc-b1e6-43e8-a639-9a6fa9e284df/old.sqlite" and "/home/runner/work/_temp/bb6847dc-b1e6-43e8-a639-9a6fa9e284df/new.sqlite"
into "/nix/var/nix/db/db.sqlite".
/usr/bin/bash -c sqlite3 /nix/var/nix/db/db.sqlite < /home/runner/work/_temp/bb6847dc-b1e6-43e8-a639-9a6fa9e284df/merge.sql
Checking the store database.
/usr/bin/bash -c sqlite3 "/nix/var/nix/db/db.sqlite" 'PRAGMA integrity_check;'
ok
Searching for a cache using the "restore-prefixes-first-match":
["nix-Linux-5d8aa1663a7b1fa3908160613db3082990513dc6f220490f58e278604f59ab79"]
Lookup only - skipping download
Found a cache using the "restore-prefixes-first-match".
Copying "/nix/var/nix/db/db.sqlite" to "/home/runner/work/_temp/7b5b1f43-9e24-416b-af4f-2b86d9465f47/old.sqlite".
Restoring a cache with the key "nix-Linux-5d8aa1663a7b1fa3908160613db3082990513dc6f220490f58e278604f59ab79-880ef0004b92be6813dd054d992a06382d688d9bd2cf3cc7c8201dc7ab670084".
Logs produced while restoring a cache.
Finished restoring the cache.
Copying "/nix/var/nix/db/db.sqlite" to "/home/runner/work/_temp/7b5b1f43-9e24-416b-af4f-2b86d9465f47/new.sqlite".
Merging store databases "/home/runner/work/_temp/7b5b1f43-9e24-416b-af4f-2b86d9465f47/old.sqlite" and "/home/runner/work/_temp/7b5b1f43-9e24-416b-af4f-2b86d9465f47/new.sqlite"
into "/nix/var/nix/db/db.sqlite".
/usr/bin/bash -c sqlite3 /nix/var/nix/db/db.sqlite < /home/runner/work/_temp/7b5b1f43-9e24-416b-af4f-2b86d9465f47/merge.sql
Checking the store database.
/usr/bin/bash -c sqlite3 "/nix/var/nix/db/db.sqlite" 'PRAGMA integrity_check;'
ok

To Reproduce

Expected behavior

The workflow should skip restore-prefixes-first-match when a cache has already been found, as described in the documentation.

Additional context

[deemp]

@kristoff3r, can I see your workflow?

[kristoff3r]

@kristoff3r, can I see your workflow?

The workflow is in a private work repository, is there something specific you're looking for or is it just for testing? I can try to make a small repository that replicates it if needed.

The only steps before the snippet above are:

      - uses: actions/checkout@v4
      - uses: nixbuild/nix-quick-install-action@v28

and it runs on ubuntu-latest.

[obreitwi]

Experiencing the same issue (with the same configuration), also in a private repository: The same cache is effectively extracted twice.

[deemp]

@kristoff3r, @obreitwi, will try to resolve the issue this week. Was busy recently

[obreitwi]

will try to resolve the issue this week. Was busy recently

No worries, take your time!

[deemp]

@obreitwi, @kristoff3r, please check v5.2.1 or v5 if v5.2.1 isn't available.