Store cache is re-saved on every run in jobs without a container #78

Summary

With cache: true, v3.1.1 never skips the post-step save in jobs that run directly on the runner. The store's contents don't change. The post step sees a different fingerprint only because the store had an empty index.db-wal right after the restore, and the project install deleted it. Container jobs skip the save as expected.

Repro: https://github.com/shahmir-oscilar/pnpm-setup-store-skip-repro (run 38620545293)

Environment

• pnpm/setup v3.1.1 (a0881977), pnpm 12.4.1, runtime: node@24, cache: true
• GitHub-hosted ubuntu-24.04

Observed

Each check job restores the store saved earlier in the run, an exact lockfile match. scripts/fingerprint.sh records what src/store-fingerprint hashes: the size and mtime of index.db, index.db-wal, and each files/xx directory.

runner-split-check uses install: false and runs pnpm install --frozen-lockfile as its own step:

after setup:   index.db-wal 0 bytes
pnpm install:  Already up to date
after install: index.db-wal none   (no other entry changed)
post step:     Cache saved with the key: …

Cause

Without a container, the project store is inside dest, the same store the runtime install uses. When fingerprintRestoredStore runs, that store has a 0-byte index.db-wal. The project install opens and closes the database, SQLite deletes the empty log, and the post-step fingerprint no longer matches.

We haven't confirmed whether the empty index.db-wal comes from the runtime install or from the restored archive.

Suggested fix

Treat a 0-byte index.db-wal the same as a missing one in fingerprintStore.

Drafted by Claude Code