cache: post-step pnpm store prune strips the store before saving, so the cache restores almost nothing #67

Summary

With cache: true, the post step runs pnpm store prune right before saveCache. In our workspace that prune removes ~97% of the packages the job just installed. The saved entry is a small remnant, and the next job downloads nearly everything again.

Observed (v3.0.0 @ fbda4c8, pnpm 12.8.1, ubuntu-24.04-arm hosted runner)

Setup: PNPM_CONFIG_STORE_DIR=${RUNNER_TOOL_CACHE}/pnpm-store, install: false, then pnpm install --frozen-lockfile in a later step. node_modules is still in place when the post step runs.

Job log, in order:

Cache restored from key: pnpm-cache-Linux-arm64-…-<lockfile hash>-…-<runId>-1-<uuid>
Cache Size: ~111 MB (116335051 B)
…
Progress: resolved 1865, reused 9, downloaded 1817, added 1865, done
…
Running pnpm store prune...
Removed 111567 files (1728629449 bytes)
Removed 1810 packages
Cache saved with the key: pnpm-cache-Linux-arm64-…

So every run restores ~111 MB, reuses 9 of 1865 packages, downloads the rest, prunes 1.7 GB, and saves another ~111 MB remnant. The store cache adds restore, prune and save time without saving any downloads.

For comparison: with cache: false and a plain actions/cache on the same store path (lockfile-hash key), the entry is ~533 MB, and a warm job logs reused 1865, downloaded 0.

Expected

The saved store should contain what the job's install used. Either don't prune before saving, or prune only packages the current lockfile doesn't reference, so a warm restore covers the install.

I haven't worked out why store prune treats packages as unreferenced while the project's node_modules still hard-links them (possibly store-v11 project registration, or the pnpm binary living in dest under runner.temp). Even if that's a separate pnpm bug, pruning just before the save turns any false positive into a useless cache.

Related

• Restore-only store caching and skip-save on exact hit #62: one full save per job because of the runId-attempt-uuid key. Together with this issue, each job in a run uploads its own copy of the pruned remnant.