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
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:
The run used
Neonsy/setup@703c52620218391530e48b9e8870d5c0082e1b9b. That is also the current upstreampnpm/setupmain commit, not a fork-only implementationRelevant inputs:
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 callssaveVerificationCache(1)after installation.runPost()later callssaveVerificationCache()without a limitIn 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 uploadExpected 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