cache/save: Silence Cache already exists warnings

[reet-]

Hi,

I'm migrating an existing workflow from cache@v3 to cache/restore@v3 and cache/save@v3 respectively. The aim is to only save the cache if on the default branch of the repository.

Everything seems to work as expected, but multiple parallel jobs use the same cache, and this now leads to many warnings like the following:

Failed to save: Unable to reserve cache with key linux-submod-***-97d0469c1e6de6b70e69684404cdc228c5e5c4c8, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/devel-ghcr, Key: linux-submod-***-97d0469c1e6de6b70e69684404cdc228c5e5c4c8, Version: 06dbd2259c1f3ad3a14e26a0d2890594e6a9283938f52ca4cfc493b01d6ad6fa

See here for an actual workflow run: https://github.com/codelabs-ch/muen/actions/runs/4460336377

I guess the behavior is expected, and this warning was not displayed when using cache@v3 directly. Is there a way to avoid/accept/silence it?

Thanks reto

[kotewar]

Hi @reet- 👋🏽

This warning would only come when the cache doesn't exist and multiple jobs are trying to create the job. The next time your workflow runs and looks for the same key, cache-hit will be set to true as it will be found, so you shouldn't see these warnings given the jobs run before the cache is evicted.

This warning will also come with cache@v3 when the cache doesn't exist and there's a cache miss for all the jobs in the matrix the very first time and we have kept this warning for users to know that they're trying to create an already existing cache to let them know that cache is immutable.

To get rid of these warnings, you can modify your workflow to something like what our fellow action users are using - https://github.com/actions/cache/issues/901#issuecomment-1343377184

But again this is only needed if your workflows run rarely (i.e. after cache gets evicted).

[reet-]

Hi @kotewar

Thanks for your helpful reply.

This warning would only come when the cache doesn't exist and multiple jobs are trying to create the job. The next time your workflow runs and looks for the same key, cache-hit will be set to true as it will be found, so you shouldn't see these warnings given the jobs run before the cache is evicted.

Yes, I'm already using cache-hit to avoid the warnings if an exact key hit happens on restore, this works well. However, the warnings are always displayed when the default branch is updated:

• restore happens on a partial key match
• all three caches have a new key
• multiple parallel jobs are trying to save the new key
• warnings are displayed

This warning will also come with cache@v3 when the cache doesn't exist and there's a cache miss for all the jobs in the matrix the very first time and we have kept this warning for users to know that they're trying to create an already existing cache to let them know that cache is immutable.

Ah ok, thanks for the clarification, I missed that then.

To get rid of these warnings, you can modify your workflow to something like what our fellow action users are using - #901 (comment)

I don't exactly understand how this relates to my problem, can you please elaborate? In my case, the cache needs to be saved since the exact key changes, and since all jobs are trying to do this in parallel, the warnings appear. I tried to use the gh-actions-cache extension, but found it to be prone to a race condition (if performed in a separate step):

• the step checks if the cache exists -> no
• the save step intends to save, but another job already created the cache entry in the meantime -> warning

[kotewar]

I don't see any issue in your workflow since you're only saving on cache-hit, but if there are cases where there will be changes in cache always, cache-hit will be set to false most of the times.

I don't exactly understand how this relates to my problem, can you please elaborate?

I just shared a use case where users are getting the cache created and stored in first step and in subsequent steps they are only restoring the cache multiple times. In your case, you are restoring cache multiple times, but saving is required only once, so multiple attempts of saving with same key will result in that issue.

the save step intends to save, but another job already created the cache entry in the meantime -> warning

This is the expected behaviour as all the save actions are trying to save the same cache. And these are just kept as warnings for users to know, the overall completion status is still success.

I guess the behavior is expected, and this warning was not displayed when using cache@v3 directly. Is there a way to avoid/accept/silence it?

To answer your question, as of now, no there's no way to silence it.

[reet-]

Could I factor out cache saving into a subsequent job, not part of the matrix? What is the scope of the cache?

[kotewar]

Could I factor out cache saving into a subsequent job, not part of the matrix? What is the scope of the cache?

I don't think this would be possible. The cache is scoped to its job only. However you can use upload-artifact and download-artifact actions to access data across the jobs.

[reet-]

Thanks @kotewar for your help. I think it is easier to just leave the workflow as-is and don't care about the warnings.

[kotewar]

You are welcome @reet-. 👍🏽

And I'd very much agree its fine to ignore the warnings given the design of the workflow and the working of the action 😄