Wrong cache restored using cache@v3.0.8

After upgrading to v3.0.8, we’ve experienced failing builds. We were building our app using a matrix with different language versions.

      - name: Cache compiled .beam files
        id: beam_cache
        uses: actions/cache@v3.0.8
        with:
          path: _build
          key: ${{ matrix.os }}-${{ matrix.elixir-version }}-${{ matrix.otp-version }}-build-${{ hashFiles('mix.lock', 'config/config.exs', 'config/prod.exs', 'config/test.exs', 'config/dev.exs') }}

The build was failing with an error saying that the project was compiled with a higher version of OTP even though:

• matrix.otp-version was in the key
• there was no restore-keys option present, so only exact matches were used

We’ve deleted all caches using gh command line utility, and we’ve noticed that it consistently fails on a rerun.

We’ve deleted most tasks to debug the problem and stopped using the matrix. We’ve tried printing sha1sum in the job right after bringing back the cache and at the end of the job:

      ... (cache action from above)
      - name: Print _build/prod/lib/telemetry/ebin/telemetry_handler_table.beam hash
        run: sha1sum _build/prod/lib/telemetry/ebin/telemetry_handler_table.beam || echo "File not present"

      ... (other things and at the end, the same thing again without echo) ...
      - name: Print _build/prod/lib/telemetry/ebin/telemetry_handler_table.beam hash
        run: sha1sum _build/prod/lib/telemetry/ebin/telemetry_handler_table.beam

and we’ve noticed that: a) when the cache is empty, we get:

• “File not present” in the first hashing task
• and some hash (First Hash) in the one running at the end

b) when re-running the job, we get:

• a different hash (Second Hash) in the first task
• and then Second Hash at the end

That means subsequent tasks did not modify the file on a cache hit. The problem rendered our builds permanently broken.

We’ve downgraded the task to use actions/cache@v2, and the problem disappeared. With v2, the hash of the file at the end of the cold run is the same as after bringing back the cache.

I believe the problem lies in caching action bringing back a different cache that was supposed to be deleted using the command line, so I decided to report the issue here.

[tomekowal]

Hey, sorry for not responding. I didn’t manage to squeeze time to reproduce it. I downgraded to cache v2 to save time on debugging. Since nobody else is facing the issue and I won’t have time to reproduce it soon, I’ll close it.

Thank you for your time and responses!

[tomekowal]

v3.0.7. I’ve merged the change to v3.0.8 on 22-08-2022. At first, I thought that it is a problem with our actions and I only had the chance to investigate thoroughly yesterday.