Github-hosted runner-generated cache entry not found from self-hosted runner using action (though findable through REST API)

I run workflows using both Github-hosted runners and self-hosted runners. When a Github-hosted runner stores an artifact in the cache, the self-hosted runner does not find it, even though it is using exactly the same key. I printed out the binary representation of both keys and confirmed they are identical (no hidden characters, etc).

In fact, from the self-hosted runner: if I use curl to search the cache for the key using the REST API, it does find the entry. It just doesn't find it through the action.

The same is true in the other direction, as well (a Github-hosted runner does not get a cache hit for a cache entry with the correct key if it was generated by a self-hosted runner).

The below example is from when the cache entry was added by a Github-hosted runner and cannot be found using actions/cache by the self-hosted runner, and yet it can be found from the same self-hosted runner workflow using curl and the REST API:

Here's the workflow step where I query the cache with the REST API from the self-hosted runner:

      - name: Debug cache API lookup
        shell: bash
        run: |
          # recompute the same key you use for actions/cache
          python_version=$(cat .python-version)
          CACHE_KEY="${RUNNER_OS}-${python_version}-${{ hashFiles('pyproject.toml','setup.cfg','requirements.txt') }}"
          echo "Looking up cache key: $CACHE_KEY"

          # call the public REST endpoint with GITHUB_TOKEN
          curl -fsSL \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
            "https://api.github.com/repos/${{ github.repository }}/actions/caches?key=${CACHE_KEY}" \
          | jq .

and here is the output from the self-hosted runner workflow:

Run # recompute the same key you use for actions/cache
Looking up cache key: Linux-3.12.3-b7dbd3ea392a6a23acbfac7fae36dded9622e49c3fa5824b0b[16](my_step_and_line_number)my_hash
{
  "total_count": 1,
  "actions_caches": [
    {
      "id": my_id,
      "ref": "refs/heads/main",
      "key": "Linux-3.12.3-b7dbd3ea392a6a23acbfac7fae36dded9622e49c3fa5824b0b168cfa64a66cc1",
      "version": "my_version",
      "last_accessed_at": "my_info",
      "created_at": "more_info",
      "size_in_bytes": 2883415849
    }
  ]
}

One of the next steps is:

    - name: Python venv caching
      uses: actions/cache@v4.2.3
      id: cache-venv
      with:
        path: ${{ env.VENV_CACHE }}
        key: ${{ runner.os }}-${{ steps.get-python-version.outputs.python_version }}-${{ hashFiles('pyproject.toml', 'setup.cfg', 'requirements.txt') }}

Here is the output from this (on the self-hosted runner):

Run actions/cache@v4.2.3
Cache not found for input keys: Linux-3.12.3-b7dbd3ea392a6a23acbfac7fae36dded9622e49c3fa5824b0b168cfa64a66cc1

Note: this is using actions/cache version 4.2.3.

Both the self-hosted runner and the Github-hosted runner are running Ubuntu 24.04 LTS.

Start by reproducing the workflow using actions/cache@v4.2.3 on both GitHub-hosted and self-hosted Ubuntu 24.04 runners, comparing the action lookup with the shown REST API request. Inspect the cache lookup path and its handling of runner types, then verify that a cache created on either runner is found by the other while preserving the existing key behavior.