Skip to content
Latchkey

actions/cache "Unable to reserve cache ... another job may be creating" in CI

Before uploading, actions/cache reserves the key with the cache service. When two jobs in the same run use an identical key at once, the second loses the reservation race and logs "Unable to reserve cache ... another job may be creating this cache". The first job still saves it.

What this error means

A post step warns "Failed to save: Unable to reserve cache with key X, another job may be creating this cache." The job is not failed, but this run did not save under that key.

actions/cache
Failed to save: Unable to reserve cache with key node-cache-Linux-a1b2c3, another job may be creating this cache.

Common causes

Parallel matrix jobs share one cache key

Several matrix legs compute the same key and try to reserve and upload it simultaneously; only the first reservation wins.

The key is not unique enough per job

A key that omits the matrix axis (OS, version, arch) collides across legs that run concurrently.

How to fix it

Make the cache key unique per matrix leg

  1. Include the distinguishing matrix variables in the key.
  2. Keep a shared restore-keys prefix so legs still benefit from each other.
  3. Re-run; each leg now reserves its own key without racing.
.github/workflows/ci.yml
key: deps-${{ runner.os }}-${{ matrix.python }}-${{ hashFiles('**/poetry.lock') }}
restore-keys: |
  deps-${{ runner.os }}-

Treat the warning as benign when keys must match

If you intentionally want one shared cache, this warning is harmless: the winning job saves it and later runs restore it. Only the duplicate save is skipped, not the build.

How to prevent it

  • Add matrix axes to cache keys so parallel legs do not collide.
  • Reserve unique keys per job and share via restore-keys.
  • Accept the race warning when a single shared cache is intended.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →