Description
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
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.
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: ...
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