Generated client output path hardcoded to build environment

[volkanunsal]

I'm trying to deploy a lambda stack to AWS using @aws-cdk/aws-lambda-nodejs. This tool spins up a local Docker machine, mounts the current project directory to asset-input and mounts the build directory to asset-output, and compiles build artifacts from a source directory and pushes them to S3 and finally updates the lambda function.

Prior to deployment, I call prism generate to generate the client for the deployment target. But this command hardcodes the output path of the client to my local machine. I've tried using an env var:

generator client {
  binaryTargets = ["native", "rhel-openssl-1.0.x"]
  provider      = "prisma-client-js"
  output        = env("PRISMA_CLIENT")
}

But it has the same effect.

I'm not sure what can be done here, short of generating the client on the lambda app.

[volkanunsal]

Here is the error I get when I hit that lambda:

Query engine binary for current platform "rhel-openssl-1.0.x" could not be found.

This probably happens, because you built Prisma Client on a different platform.
(Prisma Client looked in "/var/task/query-engine-rhel-openssl-1.0.x")

Searched Locations:
/.prisma/client
/Users/newuser/x/gr/serv/build/cdk.out/bundling-temp-fc45aec583972f9b53612ab574b1b09cf9a22cad40ebf910ba9b59e9f59ffe36/node_modules/@prisma/client
/var
/var/task
/var/task
/tmp/prisma-engines
/var/task

The path /Users/newuser/x/gr/serv/build/cdk.out/bundling-temp-fc45aec583972f9b53612ab574b1b09cf9a22cad40ebf910ba9b59e9f59ffe36/node_modules/@prisma/client is the hardcoded location of the output on my local machine.

How can I add a lookup path using an env var?

[volkanunsal]

I fixed it by copying the engine to the output path:

afterBundling(inputDir: string, outputDir: string): string[] {
  return [
    `cp ${inputDir}/node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x ${outputDir}/`,
  ];
},

I hope this is all we need from the client folder.

[janpio]

Where should the query engine binary be present in the deployment, what would be the correct path?
Can you maybe share more about how you build the project, maybe via a minimal reproduction repository?

[ryands17]

@volkanunsal 👋

From the solution, I assume you're using the CDK to bundle. One way to do this would be as shown here is generating the client directly in the asset instead of copying the query engine: https://github.com/ryands17/prisma-lambda/blob/main/lib/prisma-lambda-stack.ts#L31-L36

[volkanunsal]

Post install hook already generates it before bundling, so you can just copy that from node modules.

…

On Mon, May 24, 2021 at 1:48 AM Ryan Dsouza ***@***.***> wrote: @volkanunsal <https://github.com/volkanunsal> 👋 From the solution, I assume you're using the CDK to bundle. One way to do this would be as shown here is generating the client directly in the asset instead of copying the query engine: https://github.com/ryands17/prisma-lambda/blob/main/lib/prisma-lambda-stack.ts#L31-L36 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFAMBC6MPDVBU6YSDYZ3DTPHSCTANCNFSM45KZBB6Q> .

[millsp]

Hey, we wanted to give you an update about this. We have around 10 issues that we have identified to be in the "engine not found" category. Looking at these, we learned that there are four main categories responsible for these errors:

• Your client was generated with native (default) on one platform, but used on a different platform at runtime.
• You pinned binaryTargets incorrectly, and the correct engine was therefore not included at runtime.
• A bundler/framework changed the Prisma Client but did not copy the necessary engine for the runtime.
• Deployment/tooling did not copy the engine correctly so the correct engine was not included at runtime.

These cases were previously not detected. On top of that, the error messages were confusing and were neither helpful for you or us. With that, it is likely that many of the cases above overlapped each other. So while we cannot fix a missing engine, we can detect how and why it happened. Thanks to that, we now display more useful errors to help you out of trouble. And in some cases, we will ask some input from you to learn more about your project so we can further improve.

If something is still off for you, feel free to create a new issue.