Unknown error in SQLite Connector migrating from Prisma 3.x to 4.0.0 on ARM/M1 machines

[TasinIshmam]

Bug description

Migrating an SQLite project from Prisma 3. x to 4.00 results in an unknown error, causing the node process to terminate, without throwing any exceptions.

The error occurs whenever one tries to run any operation on the SQLite database through Prisma. Note that it only seems to affect M1 machines. I could not reproduce the bug on a Ubuntu 18.04 machine.

How to reproduce

1. Clone this repo: https://github.com/TasinIshmam/prisma-sqlite-bug-v4
2. Follow instructions in README.md

Expected behavior

Prisma should work as expected after migrating to v4 without any issues.

Actual Behavior:

An unknown issue terminates the node process, without any stack trace or bugs.

Logs in debug mode:

~/my-code/code-and-projects/work/remix/prisma-sqlite (main*) » npx ts-node index.ts                   
  prisma:tryLoadEnv  Environment variables loaded from /Users/tasinishmam/my-code/code-and-projects/work/remix/prisma-sqlite/.env +0ms
  prisma:tryLoadEnv  Environment variables loaded from /Users/tasinishmam/my-code/code-and-projects/work/remix/prisma-sqlite/.env +2ms
  prisma:client  dirname /Users/tasinishmam/my-code/code-and-projects/work/remix/prisma-sqlite/node_modules/.prisma/client +0ms
  prisma:client  relativePath ../../../prisma +0ms
  prisma:client  cwd /Users/tasinishmam/my-code/code-and-projects/work/remix/prisma-sqlite/prisma +0ms
  prisma:client  clientVersion: 4.0.0 +0ms
  prisma:client  clientEngineType: library +0ms
  prisma:client:libraryEngine  internalSetup +0ms
  prisma:client:libraryEngine:loader  Searching for Query Engine Library in /Users/tasinishmam/my-code/code-and-projects/work/remix/prisma-sqlite/node_modules/.prisma/client +0ms
  prisma:client:libraryEngine:loader  loadEngine using /Users/tasinishmam/my-code/code-and-projects/work/remix/prisma-sqlite/node_modules/.prisma/client/libquery_engine-darwin-arm64.dylib.node +0ms
[2]    45503 killed     npx ts-node index.ts

Workaround:

Clearing the node_modules folder before installing prisma version 4.0.0 resolves the problem. So one can use the following command to fix the problem: rm -rf node_modules && npm i.

Prisma information

Prisma Schema and client information are available in the reproduction repo.

Environment & setup

• OS: MacOS Monterey 12.4 (M1 Pro)
• Database: SQLite
• Node.js version: 16.14.2

Prisma Version

prisma                  : 4.0.0
@prisma/client          : 4.0.0
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine da41d2bb3406da22087b849f0e911199ba4fbf11 (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli da41d2bb3406da22087b849f0e911199ba4fbf11 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core da41d2bb3406da22087b849f0e911199ba4fbf11 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt da41d2bb3406da22087b849f0e911199ba4fbf11 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : da41d2bb3406da22087b849f0e911199ba4fbf11
Studio                  : 0.465.0

Internal

https://prisma-company.slack.com/archives/C02FZENHD4N/p1656507178534199

[millsp]

it looks like it’s that thing I’ve been constantly encountering since November or so with dev builds where macOS kills the Node.js process when trying to load the addon because our binaries aren’t signed

[aqrln]

It's not related to SQLite, it happens because macOS kills the Node.js process when trying to load the Query Engine library.

$ ts-node index.ts
zsh: killed     ts-node index.ts

$ find . -name libquery_engine-darwin-arm64.dylib.node | xargs codesign -f -s 'Oleksii Orlenko'
./node_modules/prisma/libquery_engine-darwin-arm64.dylib.node: replacing existing signature
./node_modules/.prisma/client/libquery_engine-darwin-arm64.dylib.node: replacing existing signature
./node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node: replacing existing signature

$ ts-node index.ts
0

[aqrln]

#14058

[garrensmith]

Step one for this to come up with a good way to fix this.

[aqrln]

Fixed in #14301