This is the workflow I caught red-handed: https://github.com/andreasabel/hasktorch/actions/runs/6536754694/job/17749144021

1. Version: actions/cache@v3 SHA:704facf57e6136b1bc63b828d79edcd491f0ee84 https://github.com/andreasabel/hasktorch/actions/runs/6536754694/job/17749144021
2. Cache restored from restore-key https://github.com/andreasabel/hasktorch/actions/runs/6536754694/job/17749144021#step:7:4

    Run actions/cache/restore@v3
    with:
      path: ~/.cabal/store
      key: macOS-cabal-3.6.2.0-ghc-9.2.8-plan-813f23bfbcb4c800c8178d743c3df6e501ec38580a651c180dcd99b0abc9319d
      restore-keys: macOS-cabal-3.6.2.0-ghc-9.2.8-
    ...
   Cache restored from key: macOS-cabal-3.6.2.0-ghc-9.2.8-813f23bfbcb4c800c8178d743c3df6e501ec38580a651c180dcd99b0abc9319d
   

   Note that this key is not the primary key, which has an additional -plan before the SHA.
3. The step "Cache dependencies" (if: !steps.cache.outputs.cache-hit) is skipped", it's code is https://github.com/andreasabel/hasktorch/actions/runs/6536754694/workflow

    - name: Cache dependencies
      if:   ${{ !steps.cache.outputs.cache-hit }}
      uses: actions/cache/save@v3
      with:
        path: ~/.cabal/store
        key: ${{ steps.cache.outputs.cache-primary-key }}

According to the docs, outputs.cache-hit should not be true if the cache was restored with a fallback key.
This is stressed here: