How to detect and fail for cache timeouts

[caquino]

Hi,

I'm using cache/actions to share assets between jobs. When we have multiple parallel jobs from time to time, we see timeouts with the following warning message Warning: Failed to restore: The operation cannot be completed in timeout. which makes sense considering that for typical usage, a cache should be rebuilt if it fails to restore, but in our case, we need to guarantee that the restore happened.

Besides increasing SEGMENT_DOWNLOAD_TIMEOUT_MINS to try to avoid timeouts, is it possible to make actions/cache fail if a restore times out? either by actions/cache failing or, on the next step having a way to detect that the restore failed.

Sadly cache-hit does not work for us as it requires an exact match on the key.

[wind57]

I second this, it happens to us a lot too. By the "silence" here, it surely looks like there is nothing to do.

[caquino]

Hi @wind57, to post an update here, I could not find a solution to the problem, but at least I could manage to implement a workaround.

The main issue we had was the fact that we only did a checkout on our build job, and the cache key was based on hashFiles(), so we could not do the same on the other jobs to be able to use a key that exactly matched.

To workaround that I started using a step like this:

  - uses: actions/github-script@v6
        id: cache-keys
        with:
          script: |
            core.setOutput("mvn-cache-key", "${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}" )
            core.setOutput("build-cache-key", "${{ runner.os }}-${{ github.run_id }}-build" )

and use the output to create the cache on the build job

     - uses: actions/cache@v3
        with:
          path: ~/.m2/repository
          key: ${{ steps.cache-keys.outputs.mvn-cache-key }}
          restore-keys: |
            ${{ runner.os }}-maven-

and then use these outputs as key on the cache actions, but also defining job.output for those outputs

    outputs:
      mvn-cache-key: ${{ steps.cache-keys.outputs.mvn-cache-key }}
      build-cache-key: ${{ steps.cache-keys.outputs.build-cache-key }}

With access to these outputs, I was able to change the cache step on the subsequent jobs to use specific keys and also enable fail-on-cache-miss

   - uses: actions/cache/restore@v3
        id: build-cache
        with:
          fail-on-cache-miss: true
          key: ${{ needs.build.outputs.build-cache-key }}
          path: |
            ${{ github.workspace }}/
        env:
          SEGMENT_DOWNLOAD_TIMEOUT_MINS: ${{ inputs.cache_timeout_minutes }}

Sadly I could not verify if this will fix the problem for us yet, as the cache timeout is not easy to replicate, but things are looking stable so far.

I know this is specific to my case, but I hope it may help you somehow think in ways that may help your workflow.

Again, this is not the solution to be able to fail if a cache download times out, but in theory it should workaround that.