fix(nix): refresh the registry pnpmDeps hash #496

Merged

gmackie merged 1 commit from fix/registry-pnpm-deps-hash into main

2026-08-27 20:17:12 +00:00

gmackie commented

2026-08-27 19:45:11 +00:00

Owner

npm-registry deployments are failing on every attempt — 8 between 17:13 and 18:52 UTC today — because pnpmDeps.hash in flake.nix no longer matches the lockfile. pnpm-lock.yaml has changed 7 times since the hash was last set (e836aeb9, 531af51b, ca1b6eca, aa59321c, 75e68362, fbd880f1, ead1b79a).

One line.

The hash was computed, not transcribed

Built .#registry on hetzner-worker against this exact tree with the hash set to a sentinel, and took what nix reported:

specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
got:       sha256-KPYVfGFQcIJpoXeea+uJpzxs7I4AWW1Ub15oHyCN69k=

That distinction earned its keep: the hash quoted in #491's original description differs from the computed one by a single character — …KPYVfGFW… vs …KPYVfGFQ…. Pushing that value would have reproduced the identical failure while looking correct.

Also verified pnpm-lock.yaml is unchanged between the tree that was built and the commit this lands on (e641b37d, 0 commits touching it since), so the hash is current rather than already re-drifted.

Why this replaces #491

#491's record is stuck on a stale cached merge-base (8cf344f2, the pre-push head), so it renders a bogus 696-file diff. Git computes merge-base(head, main) = e641b37d and a 1-file diff. Close/reopen did not clear the cache, so this is a fresh PR from the same branch.

Worth a follow-up

This is a recurring paper cut, not a one-time fix: any lockfile change silently re-drifts the hash and breaks registry deploys again, with the only symptom being failed deployments nobody is watching. Worth either deriving the hash in CI or failing loudly with the regeneration command.

`npm-registry` deployments are failing on every attempt — **8 between 17:13 and 18:52 UTC today** — because `pnpmDeps.hash` in `flake.nix` no longer matches the lockfile. `pnpm-lock.yaml` has changed 7 times since the hash was last set (`e836aeb9`, `531af51b`, `ca1b6eca`, `aa59321c`, `75e68362`, `fbd880f1`, `ead1b79a`). One line. ## The hash was computed, not transcribed Built `.#registry` on hetzner-worker against this exact tree with the hash set to a sentinel, and took what nix reported: ``` specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= got: sha256-KPYVfGFQcIJpoXeea+uJpzxs7I4AWW1Ub15oHyCN69k= ``` That distinction earned its keep: the hash quoted in #491's original description differs from the computed one **by a single character** — `…KPYVfGFW…` vs `…KPYVfGFQ…`. Pushing that value would have reproduced the identical failure while looking correct. Also verified `pnpm-lock.yaml` is unchanged between the tree that was built and the commit this lands on (`e641b37d`, 0 commits touching it since), so the hash is current rather than already re-drifted. ## Why this replaces #491 #491's record is stuck on a stale cached merge-base (`8cf344f2`, the pre-push head), so it renders a bogus 696-file diff. Git computes `merge-base(head, main) = e641b37d` and a 1-file diff. Close/reopen did not clear the cache, so this is a fresh PR from the same branch. ## Worth a follow-up This is a recurring paper cut, not a one-time fix: any lockfile change silently re-drifts the hash and breaks registry deploys again, with the only symptom being failed deployments nobody is watching. Worth either deriving the hash in CI or failing loudly with the regeneration command.

gmackie added 1 commit

2026-08-27 19:45:11 +00:00

fix(nix): refresh the registry pnpmDeps hash

CI / storybook (pull_request) Successful in 1m56s

Details

forgegraph/ci CI passed

CI / ci (pull_request) Successful in 11m13s

Details

CI / gitleaks (pull_request) Successful in 8s

Details

99c34804e7

`npm-registry` deployments have been failing on every attempt — 8 between
17:13 and 18:52 UTC today — because `pnpmDeps.hash` in flake.nix no longer
matches the lockfile. `pnpm-lock.yaml` has changed 7 times since the hash was
last set (e836aeb9, 531af51b, ca1b6eca, aa59321c, 75e68362, fbd880f1,
ead1b79a).

The value here was computed, not transcribed: built `.#registry` on
hetzner-worker against this exact tree with the hash set to a sentinel, and
took what nix reported.

    specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
    got:       sha256-KPYVfGFQcIJpoXeea+uJpzxs7I4AWW1Ub15oHyCN69k=

That matters: the hash quoted in the original PR description differs from the
computed one by a single character (…KPYVfGFW… vs …KPYVfGFQ…), which would
have reproduced the same failure while looking correct.

Verified `pnpm-lock.yaml` is unchanged between the tree that was built and the
commit this lands on, so the hash is current rather than already-drifted.

Note this is a recurring paper cut, not a one-time fix: any lockfile change
re-drifts the hash and silently breaks registry deploys again. Worth deriving
it in CI, or failing loudly with the regeneration command, as a follow-up.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>