Cache scoping miss even parent branch key exists and should match

[claycoleman]

I'm seeing a problem with child branching matching their parent branches during the cache check. I checked the caching docs for cache scopes and saw it says not only the default branch should be checked, but also the parent or upstream branches. Here's a quote from the docs:

The cache action first searches for cache hits for key and restore-keys in the branch containing the workflow run. If there are no hits in the current branch, the cache action searches for key and restore-keys in the parent branch and upstream branches.

However, the behavior i'm seeing is that i'm still getting cache misses for restore-keys when the parent branch has a cached value and the current branch has the same prefix as the parent branch. This makes me believe there's a bug in the cache scopes logic on the ACTIONS_CACHE_URL / artifactcache.actions.githubusercontent.com endpoint at /_apis/artifactcache/cache.

Here are the outputs from a recent CI build:

parent branch output (which ran and completed first):

Run actions/cache@v3
  with:
    ... config omitted ...

    key: Linux-yarn-v1-f2a5eba87e3842f3c8af956155ff7665aaa716c5195121736d43345199595a0b
    restore-keys: Linux-yarn-v1-
  
  env:
    ... env omitted ...

Received 234881024 of 397891754 (59.0%), 222.2 MBs/sec
Received 385308842 of 397891754 (96.8%), 182.9 MBs/sec
Received 393697450 of 397891754 (98.9%), 124.8 MBs/sec
Received 397891754 of 397891754 (100.0%), 112.7 MBs/sec
Cache Size: ~379 MB (397891754 B)
Cache restored successfully

Cache restored from key: Linux-yarn-v1-f2a5eba87e3842f3c8af956155ff7665aaa716c5195121736d43345199595a0b

child branch (which ran after parent branch CI):

Run actions/cache@v3
  with:
    ... config omitted ...
  
    key: Linux-yarn-v1-a3a9c5880d5a5f56809c4a05c1f01f2ddd9a86189280acfbaccb007e30578e6c
    restore-keys: Linux-yarn-v1-
  
  env:
    ... env omitted ...

Cache not found for input keys: Linux-yarn-v1-a3a9c5880d5a5f56809c4a05c1f01f2ddd9a86189280acfbaccb007e30578e6c, Linux-yarn-v1-

In this instance, I don't expect a full cache match because the keys are different (which is due to a change in our yarn.lock file, see the config below). however, i do expect the restore-keys value of Linux-yarn-v1- to match the parent branch output so that we can get a partial cache restoration.

here's the relevant snippet from our action.yml:

    - name: Setup Yarn cache
      uses: actions/cache@v3
      id: yarn-cache
      with:
        ... some config omitted ...
        key: ${{ runner.os }}-yarn-v1-${{ hashFiles('**/yarn.lock') }}
        restore-keys: |
          ${{ runner.os }}-yarn-v1-

Would really appreciate if someone could look into if there's a bug on the GitHub implementation of cache scopes.