Repository navigation
fetchPnpmDeps: fix reproducibility of pnpm v11 store index - #522703
Conversation
gepbird
left a comment
There was a problem hiding this comment.
Thanks!
Adding a test for this would be nice, it could be the same as in pkgs/test/pnpm/pnpm_11/default.nix but with fetcherVersion = 4. In my opinion we should keep existing tests (which is only one currently) for older fetcherVersions.
|
Forgive my ignorance, and just to double check, but are we certain that the sql dump output is deterministic? |
I verified it with openclaw #521248 and didn't have any issues across Linux and mac. Also with autobrr. |
|
|
That's good. Any chance of changes across sqlite versions though? Or changes throughout time? |
Not really something we can prepare for. Less problems than the last implementation. I suppose sqlite dump format is stable enough that we won't see any breakage in the future. |
Sure it is. The first step is knowing whether we need to prepare for it though. Have you checked with different versions of sqlite? In the dump is there anything that looks like it might be time/date related? |
Oh you mean in the data itself? This is already handled correctly, as we'd have hash issues already beyond the non-determinism from the db's metadata already. Or did you mean something else like order of the data? We can't really sort -n it because it's sql, but the order has been consistent so far, I didn't yet encounter any issues with that. The metadata that could be problematic (like the internal sql version of the db) is specifically removed by the dump step. It doesn't make sense to look at past versions of sqlite that aren't being used in the generation of the dump, as those will never get used. Only future versions remain relevant. Currently, there is only one version of the sqlite tool in nixpkgs. |
|
I am aware there is only one version, but if the data has change in the past it may change in the future. |
If the database dump changes after a new pnpm version, it should be caught by I'm not sure how could we improve this workflow or prepare better for upcoming breaking changes (which IMO should be only for major pnpm versions but we even get those for patch releases like #522531). Sorry for my rants, but I'm somewhat fed up with upstream. This SQLite change is our fault, we should'we tested it on all platforms and shouldnt've assumed that database files are reproducible. |
|
|
|
Weird that On the GHA build it fails before reaching the changed lines in this PR: end of autobrr logs2026-05-22T10:48:15.3021840Z autobrr-web-pnpm-deps> /nix/store/0y3vzjqz42dmyasywgr6ipcfb0nwdzvy-stdenv-darwin/setup: line 1827: 4628 Abort trap: 6 pnpm install --force --ignore-scripts --registry="$NIX_NPM_REGISTRY" --frozen-lockfile
2026-05-22T10:48:34.6122700Z error: Cannot build '/nix/store/bqa246qv6wllgkxs99s86by95x2n82aw-autobrr-web-pnpm-deps.drv'.
2026-05-22T10:48:34.6124310Z Reason: builder failed with exit code 134.
2026-05-22T10:48:34.6125080Z Output paths:
2026-05-22T10:48:34.6126610Z /nix/store/pfmli4mfwfnhwy5xh7hc1c7c8d65j9in-autobrr-web-pnpm-deps
2026-05-22T10:48:34.6127800Z Last 25 log lines:
2026-05-22T10:48:34.6128350Z > + react-select 5.10.2
2026-05-22T10:48:34.6128940Z > + react-textarea-autosize 8.5.9
2026-05-22T10:48:34.6129500Z > + stacktracey 2.2.0
2026-05-22T10:48:34.6130150Z > + tailwind-lerp-colors 1.2.6
2026-05-22T10:48:34.6130790Z > + tailwindcss 4.2.4
2026-05-22T10:48:34.6131390Z > + workbox-window 7.4.0
2026-05-22T10:48:34.6132060Z > + zod 4.4.1
2026-05-22T10:48:34.6132590Z > + zod-formik-adapter 2.0.0
2026-05-22T10:48:34.6133300Z >
2026-05-22T10:48:34.6133770Z > devDependencies:
2026-05-22T10:48:34.6134390Z > + @eslint/js 10.0.1
2026-05-22T10:48:34.6134950Z > + @rollup/wasm-node 4.60.2
2026-05-22T10:48:34.6135550Z > + eslint 10.3.0
2026-05-22T10:48:34.6136110Z > + eslint-plugin-import 2.32.0
2026-05-22T10:48:34.6138390Z > + eslint-plugin-react 7.37.5
2026-05-22T10:48:34.6139150Z > + eslint-plugin-react-hooks 7.1.1
2026-05-22T10:48:34.6139820Z > + eslint-plugin-react-refresh 0.5.2
2026-05-22T10:48:34.6140620Z > + eslint-watch 8.0.0
2026-05-22T10:48:34.6141220Z > + globals 17.5.0
2026-05-22T10:48:34.6141790Z > + ts-node 10.9.2
2026-05-22T10:48:34.6142400Z > + typescript 6.0.3
2026-05-22T10:48:34.6143120Z > + vite 8.0.10
2026-05-22T10:48:34.6143710Z > + vite-plugin-pwa 1.2.0
2026-05-22T10:48:34.6144300Z > + vite-plugin-svgr 5.2.0
2026-05-22T10:48:34.6146280Z > /nix/store/0y3vzjqz42dmyasywgr6ipcfb0nwdzvy-stdenv-darwin/setup: line 1827: 4628 Abort trap: 6 pnpm install --force --ignore-scripts --registry="$NIX_NPM_REGISTRY" --frozen-lockfile
2026-05-22T10:48:34.6147540Z For full logs, run:
2026-05-22T10:48:34.6147920Z nix log /nix/store/bqa246qv6wllgkxs99s86by95x2n82aw-autobrr-web-pnpm-deps.drv
2026-05-22T10:48:34.6155260Z error: Cannot build '/nix/store/5k8a3kbg4jibm9ds66qg144hfbsgfl77-autobrr-web-1.79.0.drv'.
2026-05-22T10:48:34.6156810Z Reason: 1 dependency failed.
2026-05-22T10:48:34.6157460Z Output paths:
2026-05-22T10:48:34.6158450Z /nix/store/hlgv0hqbal7bkhrxxgaj3ss9k53f0fx9-autobrr-web-1.79.0
2026-05-22T10:48:34.6166110Z error: Build failed due to failed dependency
2026-05-22T10:48:34.6167640Z error: Cannot build '/nix/store/g9pvza1krshbj2s4qa7wyw48byhdniws-autobrr-1.79.0.drv'.
2026-05-22T10:48:34.6168860Z Reason: 1 dependency failed.
2026-05-22T10:48:34.6169460Z Output paths:
2026-05-22T10:48:34.6170200Z /nix/store/8jmj36b0pil26disvsk1r71ly872bhlg-autobrr-1.79.0
2026-05-22T10:48:34.6171070Z error: Build failed due to failed dependencyBut passes on Hydra: https://hydra.nixos.org/build/329256136#tabs-summary Also in both cases it generates a large number of repeating warning logs: https://cache.nixos.org/log/yzgp82np1glqbszywamblgh5iwcm5c9k-autobrr-web-1.79.0.drv |
gepbird
left a comment
There was a problem hiding this comment.
Diff looks good, n8n was most likely already failing while autobrr passed once and failed once (without reaching the lines touched by this PR) on darwin.
|
My attempt #522703 (comment) was on a real darwin with sandbox relaxed, other modes (including off) cause the crash |
Make the fetcher version explicit in the test name in preparation for adding a v4 test. Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tests the SQLite dump/reconstruct code path introduced in fetcherVersion 4, which ensures reproducibility of the pnpm v11 store index. Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
261ab30 to
6f77647
Compare
|
Do we need to backport this to 26.05? |
|
@SuperSandro2000 I'd say we should, as pnpm v11 is the default in 26.05. Adding the label |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-26.05
git worktree add -d .worktree/backport-522703-to-release-26.05 origin/release-26.05
cd .worktree/backport-522703-to-release-26.05
git switch --create backport-522703-to-release-26.05
git cherry-pick -x f2ba699f37b4630d0502dfa024f3c1ffb2efab22 8255b29ce1198b4c2f432e483c59f215409852cb f09853e8b794e011bf2d24fef85a5cc0335a8911 6f776474958a15c60ba61c82772e71dc2f6d23ae |
|
This was merged before branch-off it seems :D See https://github.com/NixOS/nixpkgs/commits/release-26.05/pkgs/build-support/node/fetch-pnpm-deps |
|
It seems this changes existing build time FOD hashes. Just noticed this while upgrading a project to 26.05. I suspect people will now have stale FOD hashes and they wouldn't notice since they are already cached and wont get invalidated. Invalidation of an FOD happens through two mechanisms: "hash" eval-value changes, or "name" eval-value changes. I'm not sure if this was considered; But if this changes the build time hash, without changing the FOD eval-name. people and hydra has stale fod-derivations now. |
|
@hsjobeki Have you bisected? I don't think this PR is the reason for stale hashes, as the changes are gated behind a new fetcherVersion. I had the same thing happen on projects I packaged out-of-tree and the culprit is the upgrade from pnpm 10 to pnpm 11. You can pass |
|
😮💨 spent the last 1 hr bisecting now ^^ Seems #505103 is the actual source of the breakage. As per my comment there this is an architectural problem of complex fod-fetchers. Any change of the build-script can lead to new output hashes. |
|
This has now broken FOD hashes because of a SQLite update, as predicted. |
Can you expand on this? I've tried rebuilding a random pnpm 11 package's ( |
|
@gepbird There is currently a discussion on Matrix It's broken on staging-next following an update of SQLite from 3.51.2 to 3.53.1. EDIT: Credits to |

The pnpm v11 store uses a SQLite database (index.db) whose binary format
is non-deterministic across platforms (version-valid-for number, etc).
This caused hash mismatches when building the same pnpmDeps on different
machines despite identical logical content.
Fix by dumping the SQLite database to a text SQL file during the fetch
phase and reconstructing it during the build phase. This ensures the
stored representation is fully deterministic.
See #521248 (comment) for context on how this issue surfaced in openclaw package
Assisted-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.