Cache Stuck

[ScottPierce]

Describe the bug
All my actions are running, but are refusing to cache with the same error:

Post job cleanup.
Unable to reserve cache with key Linux-modules-0c1e633988f0463573ae79cec4e4e741153037a6a270a901c8bf040b3d674a4f, another job may be creating this cache.

There must be some sort of race condition, and the cache is stuck, because they all have the same precache log:

Run actions/cache@v2
  with:
    path: **/node_modules
    key: Linux-modules-0c1e633988f0463573ae79cec4e4e741153037a6a270a901c8bf040b3d674a4f
Cache not found for input keys: Linux-modules-0c1e633988f0463573ae79cec4e4e741153037a6a270a901c8bf040b3d674a4f

I imagine that if I changed my yarn lock file, which the cache is based on, this issue would resolve itself.

Expected behavior
That the cache always works, and when it gets stuck like this, it would automatically fix itself.

Additional context

• My github runner is running inside a docker container. Not deferring to a docker container, but are running inside a container where the runner is installed. I don't think this impacts things as my cache normally works.
• I don't know how to reproduce this. Normally the cache works. There just is clearly some sort of race condition where it can get stuck.

[Pentarctagon]

I've run into the same issue. Each time it starts with Cache not found for input keys: windows-master-N002 and ends with Unable to reserve cache with key windows-master-N002, another job may be creating this cache., so no cache ends up actually getting created.

[rcowsill]

I'm getting this too, on a GitHub-hosted runner. Logs are here: https://github.com/rcowsill/NodeGoat/runs/1504051837 (see the Post Use cache (docker layers) section)

In my case it's happening when the cache with the matching key already exists. Normally that would fail with the message "Cache already exists." instead of "Unable to reserve cache with key [...]"

I'm using satackey/action-docker-layer-caching@v0.0.8, which imports @actions/cache@1.0.4. In case it's important, that action is running up to four cache uploads in parallel, but all caches have unique keys within a single build. I was only running that one build using those cache keys at the time.

EDIT: I tested with parallel uploads switched off and got the same result. I'm wondering if the serverside response has been changed for the "cache exists" case to avoid retries which will never succeed.

[ScottPierce]

I've seen this happen again. This might be the initial error:

Error: Cache upload failed because file read failed with EBADF: bad file descriptor, read

[ScottPierce]

I've also noticed this is extremely reproducible for some reason. This failure happens a lot for my docker runners when things are in parallel, especially now that I have 8 runners now.

[ScottPierce]

This is now blocking the build system. I'm seeing this build error constantly:

Warning: uploadChunk (start: 100663296, end: 134217727) failed: Cache service responded with 503
/_work/_actions/actions/cache/v2/dist/save/index.js:3305
                        throw new Error(`Cache upload failed because file read failed with ${error.message}`);
                        ^

Error: Cache upload failed because file read failed with EBADF: bad file descriptor, read
    at ReadStream.<anonymous> (/_work/_actions/actions/cache/v2/dist/save/index.js:3305:31)
    at ReadStream.emit (events.js:210:5)
    at internal/fs/streams.js:167:12
    at FSReqCallback.wrapper [as oncomplete] (fs.js:470:5)

I'm going to remove caching to fix it.

[klausbadelt]

Same issue, macOS runner. Works on GitHub runner, but not local. Our key is key: ${{ runner.os }}-yarn-${{ hashFiles('web/yarn.lock') }}.

Unable to reserve cache with key macOS-yarn-5967645e7e3b673f1a9f0792c61e21863dc66df3a592de7561b991f867052c7b, another job may be creating this cache

[christianchownsan]

I think we encountered this problem by manually cancelling a run that had begun caching with a certain key before it completed the caching step. It seemed to never released the key, and subsequent runs that try to use the same key fail to reserve it:

Run actions/cache@v2
Cache not found for input keys: <key>

...

Post Run actions/cache@v2
Post job cleanup.
Unable to reserve cache with key <key>, another job may be creating this cache.

Our only workaround was to change the key.

[bilelmoussaoui]

I'm also experiencing this issue with my custom github action, it seems that it really insists on the cache key being "unique"? otherwise it keeps failing with Error: Failed to save cache: ReserveCacheError: Unable to reserve cache with key flatpak-builder-0f51bddf4f15c39e39b55b6c92c8249d99d44205, another job may be creating this cache. Except there are 0 other jobs running at the same time. The issue can be triggered by re-running a workflow job that just created the cache.