Post step caches lockfile verification log rejected by the install step #55

The install step can reject a lockfile verification log because it grew by more than one record, but the post step then uploads it anyway. The job succeeds despite the earlier warning saying the log will not be cached

Observed behavior

Successful workflow run, with relevant log lines in order:

Lockfile verification cache is not found
Warning: The lockfile verification log gained 2 records during the install, expected at most 1; not caching it.
Post job cleanup.
Lockfile verification cache saved with the key: pnpm-lockfile-verified-Linux-x64-acd23412b50a7103f44bbc0a14eca0d7c5fd96c5f0c5bc4d50fd02adb23280a3

The run used Neonsy/setup@703c52620218391530e48b9e8870d5c0082e1b9b. That is also the current upstream pnpm/setup main commit, not a fork-only implementation

Relevant inputs:

uses: Neonsy/setup@703c52620218391530e48b9e8870d5c0082e1b9b
with:
  working-directory: projects
  require-lockfile: true
  cache: true
  runtime: node@24.21.0

The runner was Linux x64. Setup downloaded pnpm 12.4.1, while the workspace install reported pnpm 12.3.4. I have not isolated why this install appended two records, so the run is an observed case rather than a minimized reproduction

Code path

In src/index.ts at the affected commit, runMain() snapshots the log and calls saveVerificationCache(1) after installation. runPost() later calls saveVerificationCache() without a limit

In src/lockfile-verification-cache/index.ts, the default limit is Infinity. A failed growth check returns without persisting a rejection state. The post process reads the same pre-install snapshot, but the two added records now pass the unlimited growth check, allowing the upload

Expected behavior

Once the install step rejects the verification log, the post step should not publish it. In particular, post-job cleanup should not relax the growth limit that rejected the log during installation

A regression test covering the main/post process boundary could assert that a log rejected for two added records remains uncached during post cleanup. Whether two records are legitimate for this pnpm configuration is a separate question from preserving that rejection

Related reports checked before filing: #37 concerns caching the wider metadata directory, and #40/#43 concern partial package-store caches. This report concerns a successful install whose verification-log cache is explicitly rejected and then saved