Investigate necessitate of the binary targets in the prisma schema.

[alasdairwilson]

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-3.0.x", "linux-musl-openssl-3.0.x"]
  enums         = true
}

This change to binary targets to add musl to the existing debian openssl was added in #300 as an emergency fix to an outage that occurred due to a redeploy while there was an active course that day. The wisdom of this notwithstanding (🤣 ) I can only assume the issue was either caused by the image update in #290 which had never been deployed and so might have broken it or a change in fly.io machine configuration.

I question whether we should be defining binaryTargets here at all, but it does work for now (and hopefully forever).

[eatyourgreens]

I've been seeing errors about Prisma falling back to OpenSSL 1.1.1, but that was EOL in September 2023, and not supported by Node since Node 16.
https://openssl-library.org/post/2023-09-11-eol-111/

gutenberg-1  | Prisma Client could not locate the Query Engine for runtime "linux-musl-arm64-openssl-3.0.x".
gutenberg-1  | 
gutenberg-1  | This happened because Prisma Client was generated for "linux-musl-arm64-openssl-1.1.x", but the actual deployment required "linux-musl-arm64-openssl-3.0.x".
gutenberg-1  | Add "linux-musl-arm64-openssl-3.0.x" to `binaryTargets` in the "schema.prisma" file and run `prisma generate` after saving it:
gutenberg-1  | 
gutenberg-1  | generator client {
gutenberg-1  |   provider      = "prisma-client-js"
gutenberg-1  |   binaryTargets = ["native", "debian-openssl-3.0.x", "linux-musl-openssl-3.0.x", "linux-musl-arm64-openssl-3.0.x"]
gutenberg-1  | }
gutenberg-1  | 
gutenberg-1  | The following locations have been searched:
gutenberg-1  |   /app/node_modules/.prisma/client
gutenberg-1  |   /app/node_modules/@prisma/client
gutenberg-1  |   /tmp/prisma-engines
gutenberg-1  |   /app/prisma
gutenberg-1  |     at Rn.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:174:7601)
gutenberg-1  |     at Rn.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:174:6754)
gutenberg-1  |     at /app/node_modules/@prisma/client/runtime/library.js:177:3010
gutenberg-1  |     at async /app/node_modules/@prisma/client/runtime/library.js:177:3225
gutenberg-1  |     at async t._executeRequest (/app/node_modules/@prisma/client/runtime/library.js:177:11403)
gutenberg-1  |     at async l (/app/.next/server/pages/api/event.js:1:810)
gutenberg-1  |     at async K (/app/node_modules/next/dist/compiled/next-server/pages-api.runtime.prod.js:20:16881)
gutenberg-1  |     at async U.render (/app/node_modules/next/dist/compiled/next-server/pages-api.runtime.prod.js:20:17520)
gutenberg-1  |     at async NextNodeServer.runApi (/app/node_modules/next/dist/server/next-server.js:598:9)
gutenberg-1  |     at async NextNodeServer.handleCatchallRenderRequest (/app/node_modules/next/dist/server/next-server.js:269:37)
gutenberg-1  |     at async NextNodeServer.handleRequestImpl (/app/node_modules/next/dist/server/base-server.js:817:17)
gutenberg-1  |     at async invokeRender (/app/node_modules/next/dist/server/lib/router-server.js:173:21)
gutenberg-1  |     at async handleRequest (/app/node_modules/next/dist/server/lib/router-server.js:350:24)
gutenberg-1  |     at async requestHandlerImpl (/app/node_modules/next/dist/server/lib/router-server.js:374:13)
gutenberg-1  |     at async Server.requestListener (/app/node_modules/next/dist/server/lib/start-server.js:141:13) {
gutenberg-1  |   clientVersion: '4.16.2',
gutenberg-1  |   errorCode: undefined
gutenberg-1  | }

[eatyourgreens]

I've only done limited testing locally, but upgrading the Prisma client (#316) seems to fix the OpenSSL errors when I build the Docker image on my MacBook.

[alasdairwilson]

I've only done limited testing locally, but upgrading the Prisma client (#316) seems to fix the OpenSSL errors when I build the Docker image on my MacBook.

This was fixed in #314 in commit 2283a01

which is included in the head of #316 so I suspect that is why it was fixed.

The real down low on why that was broken by #309 is that the problem it was fixing was inadvertently preventing an issue: the runner was set to node 20.9-alpine which used alpine 3.18 and the builder was set to 20-alpine which uses alpine 3.21. This was changed in that pr.

Prisma downloads ssl-dependent engines when npm/yarn install is run, there is no incompatibility between v4 and v6 as in both can run on any ssl version.

[eatyourgreens]

I still get OpenSSL errors locally, even with #314. I'm not sure what the problem is. Architecture maybe? I'm building the Docker image on an M3 MacBook. The errors vanish in #316. It could well be that I'm just doing something wrong when I build the app.

Prisma 6 drops support for Node 16, so that might drop support for OpenSSL 1.1.1.
https://www.prisma.io/docs/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-5#nodejs-minimum-version-change

[alasdairwilson]

That is strange! Prisma 6 continues to support openssl 1.0, 1.1 and 3.x. I dunno this issue then.

There were unique problems on mac builds on friday to be fair both before and after #314, although they were all fixed by this manual openssl update.

Prisma must need to build engines for every combination of ssl (1.0.x, 1.1.x, 3.x) of prisma version and of platform, perhaps there are specific issues for combinations of prisma 4 + openssl + mac architecture but not 6, since the latest release of prisma 4 is prior to m3 then this could be why? It is certainly a deep issue.

This does need fixed then: #316 unfortunately causes a lot of issues out of the box (you already identified we must disable type checking to use it, as eslint even by itself can not run, but also it just hangs for me as it is even with that) both in dev and pre-built.

[eatyourgreens]

Here's the OpenSSL error that I get when I build and run the app, even with #314. I don't see this warning when I build #316.

gutenberg-1  | prisma:warn Prisma failed to detect the libssl/openssl version to use, and may not work as expected. Defaulting to "openssl-1.1.x".
gutenberg-1  | Please manually install OpenSSL and try installing Prisma again.
gutenberg-1  | prisma:warn Prisma failed to detect the libssl/openssl version to use, and may not work as expected. Defaulting to "openssl-1.1.x".
gutenberg-1  | Please manually install OpenSSL and try installing Prisma again.
gutenberg-1  | Environment variables loaded from .env
gutenberg-1  | Prisma schema loaded from prisma/schema.prisma
gutenberg-1  | Datasource "db": PostgreSQL database "postgres", schema "public" at "db:5432"
gutenberg-1  | 
gutenberg-1  | 16 migrations found in prisma/migrations
gutenberg-1  | 
gutenberg-1  | 
gutenberg-1  | No pending migrations to apply.
gutenberg-1  | npm notice
gutenberg-1  | npm notice New major version of npm available! 10.8.2 -> 11.1.0
gutenberg-1  | npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.1.0
gutenberg-1  | npm notice To update run: npm install -g [email protected]
gutenberg-1  | npm notice
gutenberg-1  | ! Corepack is about to download https://repo.yarnpkg.com/3.3.0/packages/yarnpkg-cli/bin/yarn.js
gutenberg-1  | ! Corepack is about to download https://repo.yarnpkg.com/3.3.0/packages/yarnpkg-cli/bin/yarn.js
gutenberg-1  |   ▲ Next.js 14.2.21
gutenberg-1  |   - Local:        http://localhost:3000
gutenberg-1  | 
gutenberg-1  |  ✓ Starting...
gutenberg-1  |  ✓ Ready in 1467ms
gutenberg-1  | https://github.com/UNIVERSE-HPC/course-material HPCu
gutenberg-1  | .material/HPCu
gutenberg-1  | true

[eatyourgreens]

The only thing I can think of is some difference between arm64 and amd64 Docker builds, but I'm just guessing.

[eatyourgreens]

This does need fixed then: #316 unfortunately causes a lot of issues out of the box (you already identified we must disable type checking to use it, as eslint even by itself can not run, but also it just hangs for me as it is even with that) both in dev and pre-built.

I tried rolling #316 back to Prisma 5.22, but that hangs at the type checking step too. 😞

[eatyourgreens]

This Prisma issue suggests manually linking the libssl library. The location changed in Alpine 3.21.

RUN ln -s /usr/lib/libssl.so.3 /lib/libssl.so.3

prisma/prisma#25817

[eatyourgreens]

Prisma fixed OpenSSL detection in 6.1.0, so that it now searches /usr/lib as well as /lib. That's probably why I'm not seeing errors on #316.

• fix(alpine): update libssl search path to include /usr/lib prisma/prisma#25824

EDIT: the fix is buried in the 'bugs fixed' section of the release notes.
https://github.com/prisma/prisma/releases/tag/6.1.0

[eatyourgreens]

The fix won't be backported to Prisma 4 or 5, so I think that rules out Node 22 for us until we upgrade Prisma. #298 might need Prisma 6.1.0 or higher.
prisma/prisma#25817 (comment)

[eatyourgreens]

I've opened #318 to symlink libssl in the runner image, but we could also build the runner from node:20-alpine3.20 to avoid breaking changes in the latest Alpine. I'm not sure which is the best option.

I haven't looked to see if there's a node:22-alpine3.20 image, for the Next.js 15/React 19 build.

EDIT: Node 22 is available on Alpine 3.20.