cache icon indicating copy to clipboard operation
cache copied to clipboard

Cache key becomes permanently reserved after timeout during CreateCacheEntry

Open OhmSpectator opened this issue 7 months ago • 0 comments

Description

We encountered a critical issue in actions/cache@v4 when the initial call to CreateCacheEntry timed out during an upload, likely due to a partial GitHub Actions outage. Here is the affected workflow file: https://github.com/lf-edge/eve/actions/runs/15297045589/workflow?pr=4892

What happened

  • During the cache upload step (post-job hook), the first API call timed out:
Attempt 1 of 5 failed with error: Request timeout: /twirp/github.actions.results.api.v1.CacheService/CreateCacheEntry

Image https://github.com/lf-edge/eve/actions/runs/15297045589/job/43028514232?pr=4892#step:18:4

  • Despite the local timeout, it looks like the cache key was reserved on the server side, preventing subsequent retries or uploads.
  • All further retry attempts failed with the misleading message:
Failed to save: Unable to reserve cache with key ... another job may be creating this cache.

Image https://github.com/lf-edge/eve/actions/runs/15297045589/job/43030968572?pr=4892#step:18:3

  • No data was uploaded, yet the cache remained permanently reserved.

Impact

Initial jobs appear successful, as the failed cache upload doesn't fail the workflow immediately.

Later jobs or workflow runs depending on the cache fail at restore time due to fail-on-cache-miss errors.

Error: Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: ...

Image

Workflow confusion occurs as the pipeline initially appears green but subsequently fails unexpectedly.

Expected Behaviour:

If the client times out and no data is uploaded, the cache key reservation should expire quickly or not occur at all.

Retry logic should handle this scenario gracefully, ensuring the reservation is cleaned up promptly.

Actual Behaviour:

A cache key with no content stays reserved, blocking all future uploads or restores for the same key.

Workaround (only effective if the key includes commit hash)

Manually update the commit hash to generate a new cache key:

git commit --amend --no-edit
git push -f

OhmSpectator avatar May 28 '25 16:05 OhmSpectator