cache restore timeouts - only on windows, only with larger (non-default) runner

in a private repo, we get timeouts trying to restore cache but only on windows and only if run with a non-standard larger runner.

• linux
  • standard runner (linux-latest) - no timeouts
  • larger runner (ubuntu: 4 cores, 16GB mem, 150GB) - no timeouts
• windows
  • standard runner (windows-latest) - no timeouts
  • larger runner (windows: 8 cores, 32GB mem, 300GB)- timeouts >= 50% of the tests

This appears to be a relatively low-level issue (maybe I'm reporting it in the wrong place) because the failure pattern is reproduced whether using actions/cache or buildjet/cache (i hoped that would fix the problem). When using either one, the pattern is the same - the cache is downloaded 100% and times out after that. The download completes in a few seconds.

This is definitely not an obvious path/configuration problem - the particular jobs that fail vary and they will all eventually succeed if rerun enough times - sometimes once, sometimes more.

Please advise on any course of action, including filing in issue in another repo.

Run actions/cache/restore@v4
  with:
    path: ./*
    key: node-Windows-20-7543a6b6e9742607c14ef5f335e2397480cc801a
    enableCrossOsArchive: false
    fail-on-cache-miss: false
    lookup-only: false
  env:
    HUSKY: 0
    NPM_VERSION: 9
Cache Size: ~98 MB (103249742 B)
"C:\Program Files\Git\usr\bin\tar.exe" -xf C:/a/_temp/daa494c4-eb25-4dc1-8206-fe5b790d519d/cache.tzst -P -C C:/a/node-mono/node-mono --force-local --use-compress-program "zstd -d"
Received 103545508 of 103545508 (100.0%), 97.7 MBs/sec
Error: The action 'Restore cache' has timed out after 2 minutes.

Start with the actions/cache/restore@v4 restore path and the logged Windows tar extraction command, then compare behavior on standard and larger Windows runners. Reproduce the intermittent timeout with the reported cache size and compare it with buildjet/cache; done means the cache restores reliably without timing out after reaching 100%.