Unable to create Prisma Docker image for AWS EC Graviton instance

Bug description

After building a Prisma Docker image on a EC2 Graviton instance, I launched this image and get this error message

UnhandledPromiseRejectionWarning: Error: Unknown PRISMA_QUERY_ENGINE_LIBRARY undefined. Possible binaryTargets: darwin, darwin-arm64, debian-openssl-1.0.x, debian-openssl-1.1.x, rhel-openssl-1.0.x, rhel-openssl-1.1.x, linux-arm64-openssl-1.1.x, linux-arm64-openssl-1.0.x, linux-arm-openssl-1.1.x, linux-arm-openssl-1.0.x, linux-musl, linux-nixos, windows, freebsd11, freebsd12, openbsd, netbsd, arm, native or a path to the query engine library.
You may have to run prisma generate for your changes to take effect.
    at Object.getPlatform (/home/node/app/node_modules/@prisma/client/runtime/index.js:36103:13)
    at async Object.instantiateLibrary (/home/node/app/node_modules/@prisma/client/runtime/index.js:36094:21)

So apparently the Prisma engine cannot be found.

The odd thing is that the error should not occur because I am currently building the image directly on the EC2 Graviton instance and I have set the build-target to native in my schema:

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["native"]
}

When I set the build-target to arm only, it gave this error message:

Warning: Your current platform `linux-arm64-openssl-1.1.x` is not included in your generator's `binaryTargets` configuration ["arm"].
    To fix it, use this generator config in your schema.prisma:
    generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "arm"]
}
    Note, that by providing `native`, Prisma Client automatically resolves `linux-arm64-openssl-1.1.x`.
    Read more about deploying Prisma Client: https://github.com/prisma/prisma/blob/main/docs/core/generators/prisma-client-js.md

If I set the platform linux-arm64-openssl-1.1.x directly as build-target, it makes no difference. So the platform linux-arm64-openssl-1.1.x does not seem to work.

How to reproduce

1. Get an AWS EC2 Graviton instance with Ubuntu 20.04
2. Install docker and follow the postinstall
3. Install docker-compose with sudo apt install docker-compose
4. Load the broken repository git clone https://github.com/friebetill/nestjs-prisma-starter-debug-arm.git
5. Copy the env file cp .env.example .env
6. Build the docker image docker buildx build --platform linux/aarch64 --tag nestjs-prisma-starter-debug-arm_nest-api .
7. Start the docker image docker-compose up -d
8. Take a look at the logs with docker logs [id-of-container]

Expected behavior

I expected that the server would start and there would be no problems. Instead I see the following error message:

(node:1) UnhandledPromiseRejectionWarning: Error: Unknown PRISMA_QUERY_ENGINE_LIBRARY undefined. Possible binaryTargets: darwin, darwin-arm64, debian-openssl-1.0.x, debian-openssl-1.1.x, rhel-openssl-1.0.x, rhel-openssl-1.1.x, linux-arm64-openssl-1.1.x, linux-arm64-openssl-1.0.x, linux-arm-openssl-1.1.x, linux-arm-openssl-1.0.x, linux-musl, linux-nixos, windows, freebsd11, freebsd12, openbsd, netbsd, arm, native or a path to the query engine library.
You may have to run prisma generate for your changes to take effect.
    at Object.getPlatform (/home/node/app/node_modules/@prisma/client/runtime/index.js:36111:13)
    at async Object.instantiateLibrary (/home/node/app/node_modules/@prisma/client/runtime/index.js:36102:21)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Prisma information

All the information is inside the repository

Environment & setup

• OS: Ubuntu 20.04
• Database: PostgreSQL
• Node.js version: node:lts

Prisma Version

Environment variables loaded from .env
prisma                  : 3.8.1
@prisma/client          : 3.8.1
Current platform        : linux-arm64-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/prisma/node_modules/@prisma/engines/libquery_engine-linux-arm64-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/prisma/node_modules/@prisma/engines/migration-engine-linux-arm64-openssl-1.1.x)
Introspection Engine    : introspection-core 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/prisma/node_modules/@prisma/engines/introspection-engine-linux-arm64-openssl-1.1.x)
Format Binary           : prisma-fmt 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/prisma/node_modules/@prisma/engines/prisma-fmt-linux-arm64-openssl-1.1.x)
Default Engines Hash    : 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f
Studio                  : 0.452.0

[friebetill]

Thanks I have now managed to get the server to start up

• without Docker (simply with yarn start) and
• with Docker without the alpine image.

The server does not start with an Alpine image, but it looks like many are having problems with it.. The Docker image is now 2.8GB without Alpine instead of 700MB, but I can live with that for now. Thanks for your tips @janpio!

[janpio]

My guess is that the binary does not exist precompiled, so I would have to compile the engine myself.

We have an ecosystem-test that runs on AWS Graviton: https://github.com/prisma/ecosystem-tests/tree/dev/platforms/aws-graviton It can successfully execute queries, using the libquery_engine-linux-arm64-openssl-1.0.x.so.node or query-engine-linux-arm64-openssl-1.0.x Query Engine: https://github.com/prisma/ecosystem-tests/blob/b3e395f3ec54fcc7944eb13b78d57ed789353ad4/platforms/aws-graviton/code/index.test.js#L28-L46

So I think you took a wrong assumption and turn there, and the problem is actually a different one. Possible?