prisma: `prisma generate` is blocked by `query-engine-rhel-openssl-1.0.x` opening in Notepad on Windows

Bug description

When I run prisma generate two instances of Notepad are launched, which block prisma generate from completing until I close them

Until I close those two windows, it will just stand there waiting.

Just as a test I did this, and it did get rid of the problem, but also doesn’t generate the binary targets I need…

How to reproduce

This is the command I run

$ node_modules/.bin/prisma generate --schema=api/db/schema.prisma

This is what my schema looks like

datasource DS {
  // optionally set multiple providers
  // example: provider = ["sqlite", "postgresql"]
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

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

model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
}

Expected behavior

I expect prisma generate to run to completion without launching Notepad

Prisma information

See above

Environment & setup

OS: Windows 10 10.0.19041
Database: SQLite
Node.js version: 14.4.0
Prisma version: 2.9.0

$ node_modules/.bin/prisma -v
@prisma/cli          : 2.9.0
@prisma/client       : 2.9.0
Current platform     : windows
Query Engine         : query-engine 369b3694b7edb869fad14827a33ad3f3f49bbc20 (at node_modules\@prisma\cli\query-engine-windows.exe)
Migration Engine     : migration-engine-cli 369b3694b7edb869fad14827a33ad3f3f49bbc20 (at node_modules\@prisma\cli\migration-engine-windows.exe)
Introspection Engine : introspection-core 369b3694b7edb869fad14827a33ad3f3f49bbc20 (at node_modules\@prisma\cli\introspection-engine-windows.exe)
Format Binary        : prisma-fmt 369b3694b7edb869fad14827a33ad3f3f49bbc20 (at node_modules\@prisma\cli\prisma-fmt-windows.exe)
Studio               : 0.296.0

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 6
Comments: 18 (15 by maintainers)

Commits related to this issue

fix(client): don't try to run non-native engines before copying Don't try to run non-native engines querying them for version when determining whether they should be overwritten during generation. T... — committed to prisma/prisma by aqrln a year ago
fix(client): don't try to run non-native engines before copying Don't try to run non-native engines querying them for version when determining whether they should be overwritten during generation. T... — committed to prisma/prisma by aqrln a year ago
fix(client): don't run engines before copying (#19225) Fixes: https://github.com/prisma/prisma/issues/4308 — committed to prisma/prisma by aqrln a year ago
driver-adapters: support XML columns in pg and neon (#4308) Fixes the "unsupported column type 142" error. — committed to prisma/prisma by aqrln 9 months ago

Most upvoted comments

(Debugged a very similar problem for https://github.com/prisma/prisma/issues/7693#issuecomment-868814030 - so took a look at this one as well)

Turns out it is trying to get the version of that binary in the process: https://github.com/prisma/prisma/blob/ad8f073b83ddd9fd6a57c01fa7ac16d75a69f0a7/src/packages/sdk/src/engine-commands/getVersion.ts#L17-L28

For the Windows one that works of course, but the Rhel or Debian one of course can not be executed on Windows - and that popups opens.

We probably want to add something here that it knows about the current platform and the platform of the binary, and only tries to execute this for the ones that can be executed as they are the same platform.

Possibly that can already happen in the loop that calls the method above in the first place: https://github.com/prisma/prisma/blob/9c287b3d45ae721f463b682651bd778cfab9d05a/src/packages/client/src/generation/generateClient.ts#L252-L295

If that version check fails, it just copies the file anyway - so on the wrong platform it could just default to that: https://github.com/prisma/prisma/blob/9c287b3d45ae721f463b682651bd778cfab9d05a/src/packages/client/src/generation/generateClient.ts#L283-L293 (The catch makes sure when it can not get a version, it returns null, but of course there the popup is already open)

janpio on Jun 25, 2021

I get the same issue on a fresh Windows 10 install, and not on WSL. binaryTargets = ["native"] works fine but not binaryTargets = ["native", "debian-openssl-1.0.x"]. At very first it seems to work (and it does), but if you generate again and the linux binary exists already, then it opens it. Delete the linux binary, and it works again. For me, the location of the binary (opened in notepad) is where the generated client’s folder is and not in the cli.

Screenshot from 2021-05-19 18-30-03

millsp on May 19, 2021

@jkomyno yeah it was just because you used the wrong env var, I realised that after I’d written the comment and added that later.

@janpio they totally are, see https://github.com/prisma/prisma/pull/19225

aqrln on May 17, 2023

Which means it is something in the generate process, that is trying to use the Debian (wrong) binary to execute for something. Wild guess: Probably some getConfig or dmmf or similar.

janpio on May 19, 2021

I can reproduce this when using prisma with wsl then using on windows with following binary targets: binaryTargets = ["native", "debian-openssl-1.0.x"]

It is more visible with the --watch flag as it hands the process.

https://user-images.githubusercontent.com/22195362/104291298-5ed00d00-54e1-11eb-8285-8663febcbda5.mp4

pantharshit00 on Jan 12, 2021