The canonical workflow describes an empty restore-keys value as an exact-only main restore, but GitHub still searches partial matches of the primary key after an exact miss. Another trusted main workflow can therefore seed a longer key that the canonical workflow restores and republishes, carrying unreachable Bun packages or Playwright browser families into the supposedly history-free snapshot. Whether any current consumer already has such a cache is not observable from the standards checkout.
Evidence
GitHub documents the cache lookup order as an exact primary-key match, partial matches of that primary key, and only then the configured restore-keys. PR #262 removes the final tier on main but does not remove primary-key prefix matching. A non-exact primary match reports cache-hit: false, so the current save condition publishes the restored and installed store under the canonical bare key.
The risk requires a same-branch, same-cache-version entry whose key extends the full canonical OS, architecture, and lock-hash key. The canonical workflow does not create that shape, but consumer-owned workflows can share the same cache namespace and path.
Concrete failure
A consumer main workflow saves playwright-Linux-X64-<current-lock-hash>-legacy for ~/.cache/ms-playwright, including a browser family newer than the current permitted Playwright CLI knows. The canonical main run has no bare exact-key entry, prefix-restores the -legacy archive despite empty restore keys, cannot garbage-collect the unknown family, and saves the inherited contents under the bare immutable key. Bun has the same carry-forward path for unreachable packages.
Suggested verification
In a temporary GitHub repository, seed a default-branch cache whose key extends the canonical full key and whose path/cache version matches. Run the canonical restore with empty restore-keys and record the matched key and cache-hit output. Then make main discard any restore whose cache-hit is not exactly true, or adopt another mechanism that demonstrably prevents primary-key prefix contents from entering publication. Ratchet the verified behavior and run the full gate.
Found while verifying #262.
The canonical workflow describes an empty
restore-keysvalue as an exact-only main restore, but GitHub still searches partial matches of the primarykeyafter an exact miss. Another trusted main workflow can therefore seed a longer key that the canonical workflow restores and republishes, carrying unreachable Bun packages or Playwright browser families into the supposedly history-free snapshot. Whether any current consumer already has such a cache is not observable from the standards checkout.Evidence
GitHub documents the cache lookup order as an exact primary-key match, partial matches of that primary key, and only then the configured
restore-keys. PR #262 removes the final tier on main but does not remove primary-key prefix matching. A non-exact primary match reportscache-hit: false, so the current save condition publishes the restored and installed store under the canonical bare key.The risk requires a same-branch, same-cache-version entry whose key extends the full canonical OS, architecture, and lock-hash key. The canonical workflow does not create that shape, but consumer-owned workflows can share the same cache namespace and path.
Concrete failure
A consumer main workflow saves
playwright-Linux-X64-<current-lock-hash>-legacyfor~/.cache/ms-playwright, including a browser family newer than the current permitted Playwright CLI knows. The canonical main run has no bare exact-key entry, prefix-restores the-legacyarchive despite empty restore keys, cannot garbage-collect the unknown family, and saves the inherited contents under the bare immutable key. Bun has the same carry-forward path for unreachable packages.Suggested verification
In a temporary GitHub repository, seed a default-branch cache whose key extends the canonical full key and whose path/cache version matches. Run the canonical restore with empty
restore-keysand record the matched key andcache-hitoutput. Then make main discard any restore whosecache-hitis not exactlytrue, or adopt another mechanism that demonstrably prevents primary-key prefix contents from entering publication. Ratchet the verified behavior and run the full gate.Found while verifying #262.