aiolabs/nsecbunkerd
8
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

flake devShell exports prisma-engines 7.x — breaks prisma migrate/validate in the dev shell #30

New issue
Open
opened 2026-06-19 13:30:21 +00:00 by padreug · 1 comment
padreug commented 2026-06-19 13:30:21 +00:00
Owner
Copy link

Summary

The nix develop devShell exports the PRISMA_* engine paths from the bare pkgs.prisma-engines, which on current nixpkgs resolves to 7.x — and 7.x no longer ships libquery_engine.node. So running prisma (validate / migrate / generate via the CLI) inside the devShell fails, even though the nix build works (because package.nix correctly pins prisma-engines_6).

Symptom

Error: Failed to fetch sha256 checksum at
https://binaries.prisma.sh/all_commits/<hash>/linux-nixos/libquery_engine.so.node.gz.sha256 - 404 Not Found

(Prisma falls back to downloading engines because the env points at a 7.x store path with no libquery_engine.node.)

Root cause

flake.nix (devShell, ~lines 46–51) exports:

export PRISMA_QUERY_ENGINE_LIBRARY=${pkgs.prisma-engines}/lib/libquery_engine.node
export PRISMA_SCHEMA_ENGINE_BINARY=${pkgs.prisma-engines}/bin/schema-engine
# ...

But pkgs.prisma-engines is now aliased to 7.x in nixpkgs. flake.nix already computes the right attr a few lines up:

prisma-engines_6 = pkgs.prisma-engines_6 or pkgs.prisma-engines;

…and package.nix uses prisma-engines_6 correctly (6.19.3, matching the @prisma/client@^6.19.0 in package.json). The devShell exports just reference the wrong attr.

Fix

Point the devShell PRISMA_* exports at prisma-engines_6 (the same attr package.nix uses), e.g.:

export PRISMA_QUERY_ENGINE_LIBRARY=${prisma-engines_6}/lib/libquery_engine.node
export PRISMA_QUERY_ENGINE_BINARY=${prisma-engines_6}/bin/query-engine
export PRISMA_SCHEMA_ENGINE_BINARY=${prisma-engines_6}/bin/schema-engine
export PRISMA_FMT_BINARY=${prisma-engines_6}/bin/prisma-fmt
export PRISMA_CLIENT_ENGINE_TYPE=binary

Workaround (used while developing #27)

Build prisma-engines_6 explicitly and export the paths by hand:

PE6=$(nix-build '<nixpkgs>' -A prisma-engines_6 --no-out-link)
export PRISMA_QUERY_ENGINE_LIBRARY="$PE6/lib/libquery_engine.node" \
       PRISMA_SCHEMA_ENGINE_BINARY="$PE6/bin/schema-engine" \
       PRISMA_QUERY_ENGINE_BINARY="$PE6/bin/query-engine" \
       PRISMA_CLIENT_ENGINE_TYPE=binary

Notes

  • Low priority (devShell convenience; CI/build unaffected), but it bit live prisma migrate diff/validate during #27.
  • The introspection-engine/PRISMA_INTROSPECTION_ENGINE_BINARY export is also stale (prisma 6 folded it into schema-engine) — clean up while in there.
## Summary The `nix develop` devShell exports the `PRISMA_*` engine paths from the **bare `pkgs.prisma-engines`**, which on current nixpkgs resolves to **7.x** — and 7.x no longer ships `libquery_engine.node`. So running `prisma` (validate / migrate / generate via the CLI) inside the devShell fails, even though the nix *build* works (because `package.nix` correctly pins `prisma-engines_6`). ## Symptom ``` Error: Failed to fetch sha256 checksum at https://binaries.prisma.sh/all_commits/<hash>/linux-nixos/libquery_engine.so.node.gz.sha256 - 404 Not Found ``` (Prisma falls back to downloading engines because the env points at a 7.x store path with no `libquery_engine.node`.) ## Root cause `flake.nix` (devShell, ~lines 46–51) exports: ```nix export PRISMA_QUERY_ENGINE_LIBRARY=${pkgs.prisma-engines}/lib/libquery_engine.node export PRISMA_SCHEMA_ENGINE_BINARY=${pkgs.prisma-engines}/bin/schema-engine # ... ``` But `pkgs.prisma-engines` is now aliased to 7.x in nixpkgs. `flake.nix` already computes the right attr a few lines up: ```nix prisma-engines_6 = pkgs.prisma-engines_6 or pkgs.prisma-engines; ``` …and `package.nix` uses `prisma-engines_6` correctly (6.19.3, matching the `@prisma/client@^6.19.0` in `package.json`). The devShell exports just reference the wrong attr. ## Fix Point the devShell `PRISMA_*` exports at `prisma-engines_6` (the same attr `package.nix` uses), e.g.: ```nix export PRISMA_QUERY_ENGINE_LIBRARY=${prisma-engines_6}/lib/libquery_engine.node export PRISMA_QUERY_ENGINE_BINARY=${prisma-engines_6}/bin/query-engine export PRISMA_SCHEMA_ENGINE_BINARY=${prisma-engines_6}/bin/schema-engine export PRISMA_FMT_BINARY=${prisma-engines_6}/bin/prisma-fmt export PRISMA_CLIENT_ENGINE_TYPE=binary ``` ## Workaround (used while developing #27) Build `prisma-engines_6` explicitly and export the paths by hand: ```bash PE6=$(nix-build '<nixpkgs>' -A prisma-engines_6 --no-out-link) export PRISMA_QUERY_ENGINE_LIBRARY="$PE6/lib/libquery_engine.node" \ PRISMA_SCHEMA_ENGINE_BINARY="$PE6/bin/schema-engine" \ PRISMA_QUERY_ENGINE_BINARY="$PE6/bin/query-engine" \ PRISMA_CLIENT_ENGINE_TYPE=binary ``` ## Notes - Low priority (devShell convenience; CI/build unaffected), but it bit live `prisma migrate diff`/`validate` during #27. - The `introspection-engine`/`PRISMA_INTROSPECTION_ENGINE_BINARY` export is also stale (prisma 6 folded it into schema-engine) — clean up while in there.
padreug commented 2026-06-20 18:47:25 +00:00
Author
Owner
Copy link

Closing as invalid — my misdiagnosis. Verified against the flake's actual pinned nixpkgs, not the system channel.

The flake pins nixos-25.05 (flake.nix:4), where the bare prisma-engines attr is 6.7.0 — which does ship libquery_engine.node (the in-flake comment at flake.nix:18-22 already says this). Confirmed by running inside the devShell:

$ nix develop -c bash -c 'echo $PRISMA_QUERY_ENGINE_LIBRARY; npm run test:integration'
ENGINE LIB: /nix/store/8dgv1x136awcxfpbmygrkvfvby2cfl9s-prisma-engines-6.7.0/lib/libquery_engine.node
# tests 13   # pass 13   # fail 0

So the devShell prisma works out of the box, and the #29 integration tests pass in nix develop with no manual engine env. The 7.x / missing-libquery_engine.node I hit during #27 was from running nix-build '<nixpkgs>' / bare npx prisma against my system channel (unstable, 7.8.0) — never the flake's devShell. Sorry for the noise.

One genuine (trivial, non-blocking) nit remains: flake.nix:50 still exports PRISMA_INTROSPECTION_ENGINE_BINARY to a binary prisma 6 no longer ships. Harmless (only consulted by prisma db pull), so not worth its own issue — will sweep it if I'm in the flake for another reason.

**Closing as invalid — my misdiagnosis.** Verified against the flake's actual pinned nixpkgs, not the system channel. The flake pins **nixos-25.05** (`flake.nix:4`), where the bare `prisma-engines` attr is **6.7.0** — which *does* ship `libquery_engine.node` (the in-flake comment at `flake.nix:18-22` already says this). Confirmed by running inside the devShell: ``` $ nix develop -c bash -c 'echo $PRISMA_QUERY_ENGINE_LIBRARY; npm run test:integration' ENGINE LIB: /nix/store/8dgv1x136awcxfpbmygrkvfvby2cfl9s-prisma-engines-6.7.0/lib/libquery_engine.node # tests 13 # pass 13 # fail 0 ``` So the devShell prisma works out of the box, and the #29 integration tests pass in `nix develop` with **no** manual engine env. The 7.x / missing-`libquery_engine.node` I hit during #27 was from running `nix-build '<nixpkgs>'` / bare `npx prisma` against my **system channel** (unstable, 7.8.0) — never the flake's devShell. Sorry for the noise. One genuine (trivial, non-blocking) nit remains: `flake.nix:50` still exports `PRISMA_INTROSPECTION_ENGINE_BINARY` to a binary prisma 6 no longer ships. Harmless (only consulted by `prisma db pull`), so not worth its own issue — will sweep it if I'm in the flake for another reason.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
dev
docs-migration-runbook
issue-9-fix-create-new-key-race
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/nsecbunkerd#30
No description provided.