Nix: When generating the client, prisma:get-platform step infers incorrect libssl version in github action under ubuntu-latest

[haaksmash]

Bug description

Updating from 4.12 to 5.2, github actions began to fail when building the project (npx prisma migrate reset --force) with this error (from DEBUG=prisma:*):

PrismaClientInitializationError: Unable to require(`/home/runner/work/webapp/webapp/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node`).
Prisma cannot find the required `libssl` system library in your system. Please install openssl-1.1.x and try again.

Details: libssl.so.1.1: cannot open shared object file: No such file or directory

It seems like prisma:get-platform thinks the native target should be 1.1:

2023-08-30T22:19:03.575Z prisma:getGenerators  neededVersions {
  "2804dc98259d2ea960602aca6b8e7fdc03c1758f": {
    "engines": [
      "libqueryEngine"
    ],
    "binaryTargets": [
      {
        "fromEnvVar": null,
        "value": "debian-openssl-1.1.x",
        "native": true
      },
      {
        "fromEnvVar": null,
        "value": "debian-openssl-3.0.x"
      }
    ]
  }
}
2023-08-30T22:19:03.582Z prisma:get-platform  Found distro info:
{
  "targetDistro": "debian",
  "familyDistro": "debian",
  "originalDistro": "ubuntu"
}
2023-08-30T22:19:03.582Z prisma:get-platform  Trying platform-specific paths for "debian" (and "ubuntu")
2023-08-30T22:19:03.583Z prisma:get-platform  Found libssl.so file using platform-specific paths: libssl.so.1.1
2023-08-30T22:19:03.583Z prisma:get-platform  The parsed libssl version is: 1.1.x
2023-08-30T22:19:03.872Z prisma:getGenerators  {
  generatorBinaryPaths: {
    libqueryEngine: {
      'debian-openssl-1.1.x': '/home/runner/work/webapp/webapp/node_modules/prisma/libquery_engine-debian-openssl-1.1.x.so.node',
      'debian-openssl-3.0.x': '/home/runner/work/webapp/webapp/node_modules/prisma/libquery_engine-debian-openssl-3.0.x.so.node'
    }
  }
}

I originally thought this was a problem with generating the client, but in the action's logs that seems to be done successfully:

Running generate... - Prisma Client
2023-08-30T22:19:04.093Z prisma:GeneratorProcess  2023-08-30T22:19:04.093Z prisma:loadEnv  project root found at /home/runner/work/webapp/webapp/package.json
2023-08-30T22:19:04.557Z prisma:GeneratorProcess  2023-08-30T22:19:04.557Z prisma:loadEnv  project root found at /home/runner/work/webapp/webapp/package.json
Running generate... - Prisma Json Types Generator
2023-08-30T22:19:04.678Z prisma:GeneratorProcess  child exited with code null on signal SIGTERM
✔ Generated Prisma Client (v5.2.0) to ./node_modules/@prisma/client in 755ms
✔ Generated Prisma Json Types Generator (3.0.0-beta.4) to ./prisma in 2.90s

This does not happen when developing locally (on darwin-arm64); the native binaryTarget is doing its job as expected.

How to reproduce

Full disclosure: I haven't minimized this. But in our case, the only change was upgrading the prisma version from 4.12.0 to 5.2.0. Previously our builds were humming along happily!

Expected behavior

I expect the OpenSSL version to be inferred as 3.0.x on a system that only has OpenSSL 3 available.

Prisma information

generator client {
  provider        = "prisma-client-js"
  binaryTargets   = ["native", "debian-openssl-3.0.x"]
  previewFeatures = ["postgresqlExtensions"]
}

Environment & setup

• OS: ubuntu-latest, which I think is 22.04
• Database: postgresql 15.3
• Node.js version: 18.16.1

Because of the node version, I wonder if it's related to #19124... but we've been on this node version for a while! However, we're not doing anything in parallel (afaik!), and the build doesn't progress to tests, so I've seen no evidence of segfaulting yet.

Prisma Version

2023-08-30T23:01:42.891Z prisma:tryLoadEnv  Environment variables loaded from /home/runner/work/webapp/webapp/.env
Current platform        : debian-openssl-1.1.x
2023-08-[30](https://github.com/Kept-Inc/webapp/actions/runs/6031096057/job/16364150658#step:11:31)T23:01:42.895Z prisma:get-platform  Found distro info:
Query Engine (Node-API) : E_CANNOT_RESOLVE_VERSION (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
{
Schema Engine           : schema-engine-cli 2804dc98259d2ea960602aca6b8e7fdc03c1758f (at node_modules/@prisma/engines/schema-engine-debian-openssl-1.1.x)
  "targetDistro": "debian",
Schema Wasm             : @prisma/prisma-schema-wasm 5.2.0-25.2804dc98259d2ea960602aca6b8e7fdc03c1758f
  "familyDistro": "debian",
Default Engines Hash    : 2804dc98259d2ea960602aca6b8e7fdc03c1758f
  "originalDistro": "ubuntu"
Studio                  : 0.494.0
}
Preview Features        : postgresqlExtensions

[janpio]

Anything special about your GitHub Action setup, or should we be able to reproduce this by creating a plain workflow that installs Prisma and tries to use it?

If so, I think that is what we are already doing at https://github.com/prisma/ecosystem-tests, concretely this run with Node 18: https://github.com/prisma/ecosystem-tests/actions/runs/6041638512/job/16395076442. I created prisma/ecosystem-tests#3881 that adds your binaryTargets to double-check if anything goes wrong.

[haaksmash]

@janpio there must be something unique about our setup or I'd expect there to be a deluge of reports for this!

Our project uses Nix to manage most of its dependencies (in our action, this is installed via https://github.com/cachix/install-nix-action); we have the nixpkgs SHA pinned to 2de8efefb6ce7f5e4e75bdf57376a96555986841. We run our commands via nix develop, so our action is actually running nix develop --command npx prisma migrate reset --force; perhaps the nix middle-man is presenting an incorrect OpenSSL version...?

[janpio]

That sounds very possible. I fear without a public workflow script we won't be able to really understand what is going on there.

[haaksmash]

Let me see if I can create a public repo that reproduces the issue! It's in my best interest if my favorite libraries play well with my favorite operating system/package managers :)

[haaksmash]

@janpio this public repo's action is demonstrating the "incorrect" openSSL resolution: https://github.com/haaksmash/prisma-20905/actions/runs/6043463892/job/16400508990#step:7:118

but... it's not crashing? somehow it's finding openssl-1.1.x.so.node despite being on ubuntu-latest...???

[haaksmash]

@janpio Reproduced the failure by adding an (essentially empty) seed script: https://github.com/haaksmash/prisma-20905/actions/runs/6043616043/job/16400924179

[janpio]

Oh, now I also see in your original post that the error is not when running the CLI in any way, but when Prisma Client tries to run some queries - which is also what happens in the seed script. Curious. I will take a look at the reproduction.

[haaksmash]

@janpio hm, i'm not sure what you mean: from my perspective as a user, it's from running the CLI! The error is happening while running prisma migrate reset --force. It's not any old query that causes the error, either; it seems like migrations are run successfully, for example.

Plus, the seed script in the reproduction repository does not run any queries; it only constructs the prisma client and then disconnects from it.

[janpio]

Yes, but if you add --skip-seed it does not fail. And if you run npx prisma db seed it does. See under the hood runs that script, and it already fails with the import when it tries to load the Query Engine. See https://github.com/janpio/prisma-20905/actions/runs/6070898710/job/16467855018

Still investigating why that crashes.

[janpio]

Ok, so the problem is somehow related to the usage of Nix. When I remove the usage of Nix, the seed step works fine: https://github.com/haaksmash/prisma-20905/pull/1/files + https://github.com/janpio/prisma-20905/actions/runs/6116184645/job/16601005039.

I know very little about Nix, does this make sense to you in any way?

[haaksmash]

Can you shed some light on what mechanism prisma is using to infer the version of openSSL to reach for? i suspect the root of the problem is going to be found there. nix-related issues i've encountered with other tools and libraries are:

• things don't typically expect to find themselves in /nix/*
• things don't typically expect to find other things in /nix/*
• there are certain situations where a nix binary can shadow a system binary when entering a development environment

however, perhaps the simplest "fix" would be to have some way to override the inference of 1.1.x to 3.x. "Trust me bro, use this version of openssl".

[haaksmash]

@janpio nudge here; I'm happy to keep looking but I'm not familiar with the inner workings of Prisma, especially once we cross the Rust boundary!

[janpio]

I can tell you that this is not on the Rust side. On the TS side, I would start in this file and understand who calls what: https://github.com/prisma/prisma/blob/a04e3499742d7246d505cb04c342d188579404d1/packages/get-platform/src/getPlatform.ts

[haaksmash]

Thank you! This is not relevant to debugging, but ironic in an Alanis Morisette way:

prisma/packages/get-platform/src/getPlatform.ts

Line 148 in a04e349

{ id: 'nixos' },

[haaksmash]

@janpio I just noticed that in your build-passing fork, the SSL version seems to be detected as 1.1.x; Does prisma choose the oldest-possible libssl...?

https://github.com/janpio/prisma-20905/actions/runs/6116184645/job/16601005039#step:6:83

Are you able to confirm that, in a non-nix setup, prisma will find 3.0.x when that's what has been demanded?

---

On my side, I've confirmed that the various SSL .so files are in the places that Prisma is looking for them, in both a nix- and non-nix command environment:

lrwxrwxrwx   1 root root        11 May 24 17:12 libssl.so -> libssl.so.3
-rw-r--r--   1 root root    598104 May 24 17:14 libssl.so.1.1
-rw-r--r--   1 root root    667864 May 24 17:12 libssl.so.3
-rw-r--r--   1 root root    418464 Feb 17  2023 libssl3.so

so... curious that it's not finding what it needs when the files appear to be there. I will keep tracing execution to see if I can better understand why the .so.node file is not present in prisma 5 but IS(?) present in prisma 4.

[janpio]

Does prisma choose the oldest-possible libssl...?

Prisma chooses a libssl that is available and works, that might be an older one sometimes. Changing this behavior would be a breaking change, it usually does not cause trouble yet, so we left it unchanged.

Are you able to confirm that, in a non-nix setup, prisma will find 3.0.x when that's what has been demanded?

Not sure what you are asking, but generally Prisma selects a OpenSSL version that works. We have only very few reports of this not working properly.

[haaksmash]

Progress update: It seems like the change was introduced between 5.0.0 and 5.1.0. You can see that the build result is different between commits on this pull request: haaksmash/prisma-20905#3

time for some bisecting!

[haaksmash]

It seems clear to me that something changed within Prisma's get-platform step between 5.0.0 and 5.1.0. In 5.0.0, we can see these log line:

2023-10-06T18:28:29.078Z prisma:get-platform  Trying platform-specific paths for "debian" (and "ubuntu")
2023-10-06T18:28:29.080Z prisma:get-platform  Found libssl.so file using platform-specific paths: libssl.so
2023-10-06T18:28:29.081Z prisma:get-platform  The parsed libssl version is: undefined
2023-10-06T18:28:29.081Z prisma:get-platform  Falling back to "ldconfig" and other generic paths
2023-10-06T18:28:29.106Z prisma:get-platform  Command "openssl version -v" successfully returned "OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

This is what I expect to happen in Ubuntu 22.04; OpenSSL 3 is what's documented by Github.

But in 5.1.0, the logs are different:

2023-10-06T18:31:34.646Z prisma:get-platform  Trying platform-specific paths for "debian" (and "ubuntu")
2023-10-06T18:31:34.649Z prisma:get-platform  Found libssl.so file using platform-specific paths: libssl.so.1.1
2023-10-06T18:31:34.650Z prisma:get-platform  The parsed libssl version is: 1.1.x

Could it be as simple as this change...?

-    return dirContents.find((value) => value.startsWith('libssl.so') && !value.startsWith('libssl.so.0'))
+    return dirContents.find((value) => value.startsWith('libssl.so.') && !value.startsWith('libssl.so.0'))

It looks like that commit was partially reverted, in 27f4f0f, but it didn't revert that SSL matching string!

@janpio wdyt? I think this is a pretty likely candidate!

[janpio]

Yes, although I would assume that was intentional. Let's see.
(Ping @aqrln)

[OzTK]

Thanks for the repro @haaksmash it was super useful to figure out a work-around!
This means I'm now stuck on Prisma 5.0.0 until this is resolved though. A good solution for me would be to be able to provide the openssl path, as that would allow it to be fully compatible with a nix setup

[janpio]

Do you understand why this one line change causes this problem on Nix systems?

[haaksmash]

@janpio i haven't reproduced this in a non-nix context, but I suspect that the problem is that, within the nix shell, there is no lower version than 3 of OpenSSL available.

Before this change, the prisma client would find libssl.so and then invoke ldconfig to determine the version of libssl that's available. Even in a nix-shell, this reports the available version and so everything works fine!

After this change, it doesn't find libssl.so. Instead, it finds libssl.so.1.1... and doesn't check ldconfig because it "knows" what version to look for based on the name of that file. But in a nix-shell, 1.1.x is not available, so here we are in a github issue 😂

I wonder if it would find libssl.so.3 on any system...? At least in my build, it seems to be taking the first possible .so.* file and treating that as "the version".

[haaksmash]

@OzTK i'm not sure what your risk tolerance is, but it seems like patch-package (at least SUPERFICIALLY) can get the build to pass successfully (and find SSL 3!), by removing that troublesome trailing .: haaksmash/prisma-20905@3d50716

I'm going to hem and haw for a little longer before deciding to use that patch in my own production system, but it does seem pretty innocuous...

[janpio]

Instead, if finds libssl.so.1.1... [...] But in a nix-shell, 1.1.x is not available,

Help me out quickly: If it finds that file, shouldn't it then also be available?
(Probably a Nix thing I don't understand)

[haaksmash]

@janpio confusion is totally understandable! The .so.* files are there because of the base image (ubuntu), but the point of the nix-shell is to limit what executables and libraries are available to a minimal set necessary for running the project. It's behaving kind of like package.json in a node project, but at the shell level... and more extreme, because it hides globally-installed "packages" unless they've been added to the project dependencies list.

This is why the build passes in your fork without the nix shell; released from the restrictions imposed by nix, the prisma client is able to access whatever is in the ubuntu image.

[janpio]

Uh, does that mean that relying on the presence of files is not a good indicator with Nix OS?
I would have expected the files to be "hidden" as well honestly, not just the functionality.

[haaksmash]

It's only an indicator that something put that file there. In a nix-shell, there is no access to binaries, libraries, or environment variables that have not been explicitly added. In a true NixOS system, I think this file would not be present in /usr/lib at all (Nix puts everything into /nix/store/, and patches environment variables and other such things so that programs with dependencies can still find them in their /nix/store locations).

I don't think it's possible for a nix-shell, from within another operating system, to hide files, or any other possible outputs of a program. It can't know whether /usr/lib/libssl.so.1.1 is something I created on purpose (and therefore, should not be hidden---maybe it's a hardlink to something? maybe my project wrote to the file?). But I have declared which binaries, libraries, and environment variables should be available to the shell; those it can safely restrict.

For my situation, I wouldn't say that the problem is that OpenSSL 1.1.x is not available; the problem is that Prisma stops looking for .so.* files after finding .so.1.1, even though my schema file requests debian-openssl-3.0.x. In my case, I'd expect Prisma to continue looking for libssl.so.3! Why else would I have 3.0.x as my binary target, after all?

[janpio]

the problem is that Prisma stops looking for .so.* files after finding .so.1.1, even though my schema file requests debian-openssl-3.0.x. In my case, I'd expect Prisma to continue looking for libssl.so.3! Why else would I have 3.0.x as my binary target, after all?

I think Prisma thinks different here: binaryTargets only defines which platforms / binary targets should be made available to Prisma Client, not which one Prisma Client should use. It figures that out via its own detection logic and then expects the matching files to be present. (The main use case for binaryTargets is so that the same project can be run on different platforms or configurations, which require different setups and hence engine files.)

By the way: You can probably route around this whole detection logic by using the environment variables that directly provide the path to the engine files to Prisma. Maybe that is a workaround for you?

[haaksmash]

Ah, that's helpful context, thank you---although it seems that the Prisma client is really determined to use 1.1.x, even if I only include debian-openssl-3.0.x in my set of targets.

Good tip about the environment variables; I'll explore that option, too!

[haaksmash]

@janpio maybe I've missed some key part of the environment variables documentation, but I'm not seeing how to use them to work around the inferred OpenSSL version.

It doesn't look like the query engine I'd need (debian-openssl-3.0.x) is getting downloaded at all into @prisma:

Run ls -al "node_modules/@prisma/engines"
drwxr-xr-x 4 runner docker     4096 Oct 13 23:45 .
drwxr-xr-x 5 runner docker     4096 Oct 13 23:45 ..
-rw-r--r-- 1 runner docker    11357 Oct 13 23:45 LICENSE
-rw-r--r-- 1 runner docker      740 Oct 13 23:45 README.md
drwxr-xr-x 3 runner docker     4096 Oct 13 23:45 dist
-rwxr-xr-x 1 runner docker 14796416 Oct 13 23:45 libquery_engine-debian-openssl-1.1.x.so.node
-rw-r--r-- 1 runner docker     1099 Oct 13 23:45 package.json
-rwxr-xr-x 1 runner docker 19523224 Oct 13 23:45 schema-engine-debian-openssl-1.1.x
drwxr-xr-x 2 runner docker     4096 Oct 13 23:45 scripts

Since that's the case, the PRISMA_QUERY_ENGINE_LIBRARY has nothing to point to. Would I need copy the correct engine into my project, and point Prisma to that...? I'd really like to avoid that, since I would definitely miss any upstream changes made 😅

edit: seems like node_modules/prisma (not /@prisma!) does have the engine after all, and using that in PRISMA_QUERY_ENGINE_LIBRARY IS enough to make the build pass again 🎉

I'm not sure I understand the difference between node_modules/prisma and node_modules/@prisma; is it definitely safe to point to files in node_modules/prisma...? Either way, it feels very odd to point to anything in node_modules! I'd much prefer a environment variable that means "don't infer your own version of OpenSSL, use THIS VERSION", but it looks like setting LD_LIBRARY_PATH didn't work out...

[janpio]

You use binaryTargets to make prisma generate download all the ones you want and need. (And the equivalent CLI env var if you also need the schema engine for migrations). Then you use PRISMA_QUERY_ENGINE_LIBRARY (and equivalent) to point to the correct one.

Your required engine for Prisma Client should actually be in the built Prisma Client, which is probably in node_modules/.prisma/client. node_modules/@prisma/engines then contains the schema engine for the CLI. The CLI directory under node_modules/prisma should actually not be needed I think. (Yes this is all a bit messy - it was not meant for your use case after all)

Either way, it feels very odd to point to anything in node_modules! I'd much prefer a environment variable that means "don't infer your own version of OpenSSL, use THIS VERSION", but it looks like setting LD_LIBRARY_PATH didn't work out...

I understand, but that does not exist right now.

[haaksmash]

I understand, but that does not exist right now.

Haha! Sorry, I'm sure it feels like I'm repeating earlier comments in this thread. Just consider it voting with my issue comments for Prisma's future roadmap!

It seems very likely that the combination of prisma generate (to populate the .prisma/ directory) and the PRISMA_QUERY_ENGINE_LIBRARY variable (to point into .prisma/) will allow me to upgrade beyond 5.0.0, which is what I care about in the short term.

Thank you very much for coming on this nix-shell journey with me, @janpio ❤️

[janpio]

Please let me know if it works out. And sorry I did not get this idea earlier.

I would suggest that you open a separate issue that we can actually turn into a feature request to reflect what you are looking for as an easier way to control this behavior.

I am unsure if we should keep an issue open to describe the general Nix problem - I am still not sure if the problem there is with Nix (showing the file but not allowing its usage), or with Prisma (somehow relying on the presence of a file that should not indicate some functionality to be available).

[haaksmash]

Personally, I think it's still worth keeping something open on the Prisma side, since there was a way to infer the working version of OpenSSL (ldconfig), and Prisma was doing that until after 5.0.0. Even if it was as naive as having Prisma try the next .so.* file, I probably wouldn't have had to go on this journey (since after .so.1.1 is my desired .so.3).

It's also kind of a catch-22 to suggest native for local development, but have native force OpenSSL 1.1.x despite Prisma's documentation suggesting that 22.04 would reach for 3 (at least, that's how I read the table a month ago 😉)! It seems like native actually means "the lowest available OpenSSL version". Maybe the real bug was in the documentation all along...?

I think it would be more complicated, but it'd be be nice to have a more specifically informative error message for folks in my situation; something like:

We tried to use OpenSSL 1.1, but that didn't work. There is another libssl.so.3 file available, but see for why Prisma will only attempt use 1.1 because the native target is specified, no matter what other binary targets are listed.

---

I will report back! At least, when the native target is not included in the binaryTargets list, and you remember to include --skip-generate to Prisma CLI commands after prisma generate, we have a green build!

[janpio]

It's also kind of a catch-22 to suggest native for local development, but have native force OpenSSL 1.1.x despite Prisma's documentation suggesting that 22.04 would reach for 3 (at least, that's how I read the table a month ago 😉)! It seems like native actually means "the lowest available OpenSSL version". Maybe the real bug was in the documentation all along...?

I think that is actually simpler: native means "local binary target of the machine this is currently running on". So it is a shortcut to darwin when you run on a machine that would choose darwin, or debian-openssl-3.0.x if that was the outcome on the local Ubuntu. So that one will be downloaded with whatever else is also set in binaryTargets. In a normal system the Client logic will then also try to load that file. (In case where you are on Ubuntu and have both 1.1.x and 3.0.x installed, we currently prefer 1.0.x for other unrelated reasons - so that would need to be the result of native as well as what the Client then tries to use)

[baptisteArno]

I'm not sure if it's 100% related but I'm trying to run an app with a nixpacks-generated Docker image. I get this error:

 PrismaClientInitializationError: Unable to require(`/app/node_modules/.prisma/client/libquery_engine-debian-openssl-3.0.x.so.node`).
 Prisma cannot find the required `libssl` system library in your system. Please install openssl-3.0.x and try again.
 
 Details: libssl.so.3: cannot open shared object file: No such file or directory
       at new e (/app/node_modules/@prisma/client/runtime/library.js:26:1871)
       at /app/node_modules/@prisma/client/runtime/library.js:114:10094
       at processTicksAndRejections (:61:76)

Here is the output of DEBUG="prisma:get-platform" prisma version executed in the container:

2024-02-06T09:22:14.392Z prisma:get-platform  Found distro info:
{
  "targetDistro": "debian",
  "familyDistro": "debian",
  "originalDistro": "ubuntu"
}
2024-02-06T09:22:14.392Z prisma:get-platform  Trying platform-specific paths for "debian" (and "ubuntu")
2024-02-06T09:22:14.393Z prisma:get-platform  Found libssl.so file using platform-specific paths: libssl.so.3
2024-02-06T09:22:14.394Z prisma:get-platform  The parsed libssl version is: 3.0.x
prisma                  : 5.8.0
@prisma/client          : 5.8.0
Computed binaryTarget   : debian-openssl-3.0.x
Operating System        : linux
Architecture            : x64
Node.js                 : v20.9.0
Query Engine (Node-API) : libquery-engine 0a83d8541752d7582de2ebc1ece46519ce72a848 (at ../../node_modules/@prisma/engines/libquery_engine-debian-openssl-3.0.x.so.node)
Schema Engine           : schema-engine-cli 0a83d8541752d7582de2ebc1ece46519ce72a848 (at ../../node_modules/@prisma/engines/schema-engine-debian-openssl-3.0.x)
Schema Wasm             : @prisma/prisma-schema-wasm 5.8.0-37.0a83d8541752d7582de2ebc1ece46519ce72a848
Default Engines Hash    : 0a83d8541752d7582de2ebc1ece46519ce72a848
Studio                  : 0.497.0

This is the output of openssl version -a executed in the container:

OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023)
built on: Tue Sep 19 13:02:31 2023 UTC
platform: linux-x86_64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
OPENSSLDIR: "/nix/store/vzajrlhsdv2d39s7v6zv09ggajs05gwj-openssl-3.0.11/etc/ssl"
ENGINESDIR: "/nix/store/vzajrlhsdv2d39s7v6zv09ggajs05gwj-openssl-3.0.11/lib/engines-3"
MODULESDIR: "/nix/store/vzajrlhsdv2d39s7v6zv09ggajs05gwj-openssl-3.0.11/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xfefa3203078bffff:0x40001c219c07a9

Node.js version: v20 (I've also tried with Node.js v18)

Prisma version: 5.8.0

Here is my schema.prisma file

It uses bun as the app package manager and runtime engine.

I just don't know how to debug that further.

Related issue: railwayapp/nixpacks#1030