Add private ResumeKws, make private SetKeywordActivationState, PauseKws

Purpose

In DialogManager class add private ResumeKws, make private SetKeywordActivationState, PauseKws.
Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

I like to good progress!
At this point, please add comments above each one of the public methods in DialogManger.h to describe what the method does. This will be our API documentation.
The following is unclear: What is the difference between  StartListening() and ContinueListening()? Why do we need both? (and an implementation note: internally you should have one call the other, if they share lines of code)

Also think about making sure each one of the public methods behaves well when called out of order or when not relevant (e.g. calling StartKWS when a .table file was not specified). Do we need to define our own set of error codes?

You can handle error codes in a seperate PR if needed.

Added brief comments above each one of the public methods in DialogManger.h.
Make ContinueListening() private, and StartListening() call ContinueListening() to remove duplicate code.
Currently, the CPP console allows user to select command at any order. There are no dependencies among commands, and no errors from repeatedly running a command. "4 [start keyword listening]" and "5 [stop keyword listening]" will be invisible if kws is not supported when a .table file was not specified. Therefore, error codes seem not that necessary. A simple and straightforward console app could be better for users to focus on essentials and let them decide what else they need for their scenario. However, if we do need error codes, we need to discuss rules should be enforced and design error codes accordingly.


feat: add plugin disable flag

Fixes #478.
For the docs entry I guessed that it will be released in version 0.20, this might have to be adjusted.
For converting the environment variable value string to a bool I copied distutils.util.strtobool, since distutils has been deprecated.
I considered adding a test but I couldn't see some obvious way to extend the test suite.

Thanks for the link @oprypin. What's the benefit of having the config value as well?

If we use the config, it's also possible to change it while hot reloading without restarting the process (but then we're back to forgetting to revert the change and accidentally committing it)
I think the test fails are unrelated to my change by the way, they're also failing on master for me.

OK I checked the docs again and I see a clear benefit to having a configuration option: it allows users to enable/disable the plugin depending on multiple environment variables. It draws the path to a convention thanks to which you can disable all plugins at once, or just specific ones:
plugins:
- plugin_a:
    enabled: !ENV [MKDOCS_ENABLE_PLUGINS, MKDOCS_ENABLE_PLUGINA, true]
- plugin_b: !ENV [MKDOCS_ENABLE_PLUGINS, MKDOCS_ENABLE_PLUGINB, true]

With this config, users can disable both plugins with MKDOCS_ENABLE_PLUGINS=no or disable just the plugin B with MKDOCS_ENABLE_PLUGINB=no.
This would allow even more grouping of plugins.
Of course all plugins should provide the same enabled or disabled options, as I don't think it's possible to say "not ENV_VAR".
So, @StephanBras, could you bring the change following what was done in the link @oprypin mentioned? Sorry for the late change of direction.

Sure, I'll do it over the weekend. Should it be an "enabled" option instead of "disabled" to be in line with others plugins then?

Yes! Thanks a lot :)


The Custom Vision portal doesn't show the already created resource

Describe the bug
Following the steps Classify endangered bird species with Custom Vision module's exercises, the Custom vision portal doesn't show the already created resource.
To Reproduce
Steps to reproduce the behavior:

Go to Classify endangered bird species with Custom Vision
Follow and complete the steps in Unit 3: Exercise - Build the model
In the next exercise, Unit 4: Exercise - Upload the data follow the steps of Option 1, until 1.b.iii
The resource is not showing in the Custom Vision portal

Expected behavior
The resource created in the previous exercise should show in the Custom Vision portal.
Screenshots

Desktop (please complete the following information):

OS: Windows 11
Browser Microsoft Edge

Additional context
In unit 3: Exercise - Build the model, I used the already existing resource group and didn't create a new one. Maybe that's where the problem is coming from. Refer to #138.

🎓 Add a tag to this issue for your current education role: student, Student Ambassador or educator.
Student Ambassador

UPDATE
The bug is fixed after navigating to the custom Vision portal from the resource itself.

This is a duplicated with https://github.com/microsoft/studentambassadors/issues/131 I will close this and follow up on the other one.


Add rainbow color  刌天绨㢵秉迁𣎴㤊风。岙义人

Parker Short says he won't create an account until we implement a rainbow color option, so I'm going to implement rainbow colors then force him to create an account.

Finished in https://github.com/michaelgira23/MyMICDS-v2-Angular/pull/10. Simply change a class color to #C01025 to activate.


Segmentation fault crash when using prisma client when using PostgreSQL

Bug description
When trying to use findMany() (or any other method) on a model, prisma client crashes and the following line appears in my log:
Segmentation fault (core dumped).
This only happens if I use PostgreSQL as far as I know, this first appeared when I switched to PostgreSQL from mysql.
How to reproduce

Initiate a new prisma project (make sure to use PostgreSQL) and generate the client - no errors there
Write a simple client which fetches some data from the databse
The script crashes and Segmentation fault (core dumped) gets logged in the console

Expected behavior
The script does not crash.
Prisma information
Example schema:
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
    id String @id
    email String?
}

Example test client:
const {PrismaClient} = require('@prisma/client');
const prisma = new PrismaClient({ log: ['query', 'info', 'warn'] })
prisma.user.findMany().then((e) => {
    console.log(e)
})

Environment & setup

OS: Pop!_OS (Linux pop-os 5.15.5-76051505-generic #202111250933~1638201579~21.04~09f1aa7-Ubuntu SMP Tue Nov 30 02: x86_64 x86_64 x86_64 GNU/Linux)
Database: PostgreSQL v14.1 (Ubuntu 14.1-1.pgdg21.04+1)
Node.js version: v17.2.0

Prisma Version
prisma                  : 3.6.0
@prisma/client          : 3.6.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at<EMAIL_ADDRESS>Introspection Engine    : introspection-core dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at<EMAIL_ADDRESS>Format Binary           : prisma-fmt dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at<EMAIL_ADDRESS>Default Engines Hash    : dc520b92b1ebb2d28dc3161f9f82e875bd35d727
Studio                  : 0.440.0

Happens here as well, pre- 3.6.0 does not have this issue. M1 mac

Any idea how to reproduce? If this was a universal things, we would have hundred of reports instead of just 2 of course - so something needs to trigger that. @sveisvei Can you please also post all the versions of all the things you are using?

I still don't know what the issue could be, but I have followed this guide to debug this issue a little bit more. I have to admit, I don't have any experience with this, but I have attached crash.log file which got generated by the segfault-handler module:
PID 19523 received SIGSEGV for address: 0x1000001b7
/home/simonc/workspace/prisma-test/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x372d)[0x7f92370cf72d]
/lib/x86_64-linux-gnu/libc.so.6(+0x46520)[0x7f9236bc4520]
/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_get_peer_certificate+0x17)[0x7f92342e4d87]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x1410427)[0x7f921565d427]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xf37b0d)[0x7f9215184b0d]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x10d8010)[0x7f9215325010]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xf7551e)[0x7f92151c251e]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xff5e62)[0x7f9215242e62]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xffdd3d)[0x7f921524ad3d]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xfd66cd)[0x7f92152236cd]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc4755d)[0x7f9214e9455d]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc6ce8b)[0x7f9214eb9e8b]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc7cd46)[0x7f9214ec9d46]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc0f64a)[0x7f9214e5c64a]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc18023)[0x7f9214e65023]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc5b5d8)[0x7f9214ea85d8]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc43c2a)[0x7f9214e90c2a]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc65e87)[0x7f9214eb2e87]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc629a4)[0x7f9214eaf9a4]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xc526a7)[0x7f9214e9f6a7]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x20a71a)[0x7f921445771a]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x20916b)[0x7f921445616b]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x1b1529)[0x7f92143fe529]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13d23d6)[0x7f921561f3d6]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13d18e8)[0x7f921561e8e8]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13bfc65)[0x7f921560cc65]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13d0d2c)[0x7f921561dd2c]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13d669f)[0x7f921562369f]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13cac68)[0x7f9215617c68]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13c9926)[0x7f9215616926]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13be02a)[0x7f921560b02a]
/home/simonc/workspace/prisma-test/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x13d5f78)[0x7f9215622f78]

Maybe this helps

Okay, well, I spend another (at least) four hours playing with things and got it to work: I basically only had to build my own engines - it works now ^^
Maybe this could help @sveisvei too :sweat_smile:

So you analysis would be that the libquery_engine-debian-openssl-1.1.x.so.node that is used by default is not compatible with the OS you are using?

Yes, probably

I am also getting a segmentation fault when using .findmany, except only when I use supabase for the PostgreSQL server.

Yes, probably

I am also getting a segmentation fault when using .findmany, except only when I use supabase for the PostgreSQL server.
My segfault crash logs also point to the same engine issue. I'm on Ubuntu 20.04. Can I get more details on the engine you are now using?

I just fixed this by using the binary engine instead of the library engine. Will there ever be a proper fix for this?

If you can provide a proper reproduction, we could potentially follow what is happening and try to fix it. Without a reproduction, it will be impossible. As @SCDerox 's initial problem probably was related to their operating system, and yours is clearly not, please open a new issue and provide all the information the bug report template asks fors @tisuela.

Tested again with 3.7.0 and a fresh install, and this does error not occur anymore.

Tested with a fresh install prisma-client @ 3.7.0, and the error did not occur anymore.

Let's close this then 👍
@sveisvei If Prisma not working on Pop!_OS is a general thing, could you maybe create an issue with reproduction steps so we can confirm this is the case and then potentially fix this? Thanks.

Tested with a fresh install of prisma-client @ 3.7.0, and the error did not occur anymore.

I'm still getting this error after doing this.

I just fixed this by using the binary engine instead of the library engine. Will there ever be a proper fix for this?

@tisuela How do I do this?
Environment: Ubuntu 20.04 LTS running on Windows WSL2
Logs:
> studio
> prisma studio -b none --schema schema.prisma

Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Prisma Studio is up on http://localhost:5555
Segmentation fault

Can you share your project? Is this reproducible on other computer?

@janpio Here are the steps to reproduce this. I used a fresh VM (Ubuntu 20.04 LTS) on Google Compute Engine. I used a fresh PostgreSQL database (try Supabase for a quick test).
npm init -y
npm install -D prisma
npm install @prisma/client
nano schema.prisma

schema.prisma:
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = "URL"
}

model User {
  id             String       @id @default(uuid())
  createdAt      DateTime     @default(now())
  updatedAt      DateTime     @updatedAt
}

npx prisma generate
npx prisma studio

Now try and view a model on localhost:5555...
Prisma Studio frontend logs:
Prisma Client Error
Unable to run script
Message: Error in HTTP Request (Status: 502)
Query:
[object Object]

Console logs:
Prisma schema loaded from schema.prisma
Prisma Studio is up on http://localhost:5555
Segmentation fault (core dumped)

Error also seen with Ubuntu 18.04 LTS on Windows WSL2. I cannot reproduce this on my home setup (Arch Linux).
Error could not be fixed by changing engine to binary (cc @tisuela)
generator client {
  provider = "prisma-client-js"
  engineType = "binary"
}

Tested with a fresh install of prisma-client @ 3.7.0, and the error did not occur anymore.

I'm still getting this error after doing this.

I just fixed this by using the binary engine instead of the library engine. Will there ever be a proper fix for this?

@tisuela How do I do this?
Environment: Ubuntu 20.04 LTS running on Windows WSL2
Logs:
> studio
> prisma studio -b none --schema schema.prisma

Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Prisma Studio is up on http://localhost:5555
Segmentation fault

@janpio Here are the steps to reproduce this. I used a fresh VM (Ubuntu 20.04 LTS) on Google Compute Engine. I used a fresh PostgreSQL database (try Supabase for a quick test).
npm init -y
npm install -D prisma
npm install @prisma/client
nano schema.prisma

schema.prisma:
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = "URL"
}

model User {
  id             String       @id @default(uuid())
  createdAt      DateTime     @default(now())
  updatedAt      DateTime     @updatedAt
}

npx prisma generate
npx prisma studio

Now try and view a model on localhost:5555...
Prisma Studio frontend logs:
Prisma Client Error
Unable to run script
Message: Error in HTTP Request (Status: 502)
Query:
[object Object]

Console logs:
Prisma schema loaded from schema.prisma
Prisma Studio is up on http://localhost:5555
Segmentation fault (core dumped)

Error also seen with Ubuntu 18.04 LTS on Windows WSL2. I cannot reproduce this on my home setup (Arch Linux).
Error could not be fixed by changing engine to binary (cc @tisuela)
generator client {
  provider = "prisma-client-js"
  engineType = "binary"
}

I also rolled back to prisma 3.5.x

Not sure if this helps but I tried using Google Cloud SQL for PostgreSQL but having the same issues:
[218]: [1-1] db=postgres,user=postgres LOG:  could not receive data from client: Connection reset by peer

Error persists when using version 3.5.0 for prisma CLI and client:
Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Prisma Studio is up on http://localhost:5555
┌─────────────────────────────────────────────────────────┐
│  Update available 3.5.0 -> 3.7.0
│
│  Run the following to update
│
│    npm i --save-dev prisma@latest
│
│    npm i @prisma/client@latest
│
└─────────────────────────────────────────────────────────┘
Segmentation fault

Note that the later comments might actually describe a different problem, as your error message does not include the (core dumped) string that was originally mentioned to be part of the `Segmentation fault" error message. But I guess it is to late now to split into its own, separate issue.

So far the messages on WSL2 have been Segmentation fault, and the messages on a Ubuntu VM have been Segmentation fault (core dumped)

I just tried this on WSL 2 and I wasn't able to reproduce this there:

I will spin up a PopOS VM now to try this there.

I am also unable to reproduce this in PopOS. Can you maybe try with LTS version of node here?

@pantharshit00 Ah, the issue is fixed for me after updating to Node 17 LTS. Previously I was on Node 14 LTS.
If you can replicate this on the lower Node version it may be worth refreshing the docs:

Note: You need Node.js (version 12.6 or higher) for this tutorial.
https://github.com/prisma/docs/blob/main/content/100-getting-started/01-quickstart.mdx

If this is failing on older Node versions, we can hopefully reproduce with that and then figure out what is going on.

I tried using client versions 3.6.0 and 3.8.1 and got the same segfault crash on Postgres 14 on Google Cloud SQL. I was running the app on an alpine container (so the bug isn't necessarily tied to Pop!_OS or Ubuntu as in the above cases). Also I'm on Node version 17.1. So this isn't about having an old Node runtime.
When I ran the same app (same container) connected to a Postgres 13 database on Google Cloud SQL it worked fine.
Note that I hadn't seen this GH issue before I reported the bug in https://github.com/prisma/prisma/issues/9545#issuecomment-1013595198

Note here that Node.js v17 is not recommended because not LTS yet.
https://nodejs.org/en/about/releases/
I would be curious to know if you can reproduce with Node.js v16, current LTS

Add the same issue running on latest node version 17.4.0. Fixed by using the current LTS 16.3.2.

I have the issue in nodes v16.15 & v18.1 after switching from AWS Aurora compatible Postgres to standard PostgreSQL on AWS.  It worked for a few hours today on node v16.15; then, it started throwing this error every time I ran a query.
Windows 11, WLS2 Ubuntu (installed from Windows store 3/14/2022 version)

I seem to be having similar problems with the node:18-alpine base image in Docker. node:16-alpine works. I'd like to use Node 18 if possible, though.

@lifedup @DePasqualeOrg Which version of Prisma are you running here?
Also @DePasqualeOrg Do you know the exact node version here? Is it 18.3.0? You can do node -v ot try node:18.3.0-alpine for example.

Just wanted to chip in as well....
I have been getting the same error, segmentation fault (core dumped) with PostgreSQL.
However I noticed it's only so with the newer versions of NodeJs, when I switched to 16.5.1 (LTS) it started working normally again.
I will test it some more then write again...

Like @zanzlender, I found that it when using node v17.9 and trying to connect to supabase, I was getting the segmentation fault. However, since I have switched to the LTS (at the time of this writing, it is v16.15.x) it works.

I facing this bug using node 17.9 and AWS RDS and Postgres. If I have Postgres installed locally, I have no problems with node 17.9

Found a solution that worked for me based on the info in this thread so I figured I should share.
I have been doing local development with no issues using docker for two months with no issues using the following versions:
postgres: 14
node:18
prisma: 3.14.1
However, once i tried to deploy on AWS I got the segfault crash others in this thread were talking about. Our solution was to downgrade to use the following versions to get things working in AWS:
Postgres: 13.4
node: 18
prisma: 4.1.0
Since there were no issue running the application in local containers, it seems like it is an issue with node version above 16 in combination with postgres 14 in cloud providers like AWS and GCP.

I've got the same issue using Node 18.7.0 and AWS RDS with Postgres 14.3.0.
Works fine with my local environment - MacBook Pro(16-inch, 2019) but when I run the script within container I got Segmentation Fault error. Both node:18.7.0 and node:18.7.0-alpine didn't work.
Here's the script that I used for test.

It worked when I downgrade node version to 16.17.0.

Can someone facing this issue send us the core dump file? We would really like to look into this!

Hi, new to the party but having the same problem. Everything works locally and in our CI, but as soon as the code is deployed to AWS ECS (fargate), then it explodes in a fiery segfault :) I have a fresh dump of the trace for the segfault.
PID 20 received SIGSEGV for address: 0x1000001b7
/app/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x2e65)[0x7f28bb3e0e65]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f28bb09c140]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_get_peer_certificate+0x13)[0x7f28b80ee143]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x11aa8e7)[0x7f28a34548e7]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xd7b92d)[0x7f28a302592d]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xf02b05)[0x7f28a31acb05]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xe892f6)[0x7f28a31332f6]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xd9fd54)[0x7f28a3049d54]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xe166e1)[0x7f28a30c06e1]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xeefe7f)[0x7f28a3199e7f]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xe28eef)[0x7f28a30d2eef]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xddf280)[0x7f28a3089280]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x81406e)[0x7f28a2abe06e]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x806399)[0x7f28a2ab0399]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x7989a5)[0x7f28a2a429a5]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x79d6a3)[0x7f28a2a476a3]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x82497f)[0x7f28a2ace97f]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x81d643)[0x7f28a2ac7643]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x805990)[0x7f28a2aaf990]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x21e72d)[0x7f28a24c872d]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x254f35)[0x7f28a24fef35]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x1fa535)[0x7f28a24a4535]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x20d76d)[0x7f28a24b776d]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x1f13c6)[0x7f28a249b3c6]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x17e34d)[0x7f28a242834d]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x184e3e)[0x7f28a242ee3e]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x118c025)[0x7f28a3436025]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x117c693)[0x7f28a3426693]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x117bb9e)[0x7f28a3425b9e]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x118dae7)[0x7f28a3437ae7]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x117b5bb)[0x7f28a34255bb]
/app/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x1192d21)[0x7f28a343cd21]
Segmentation fault

Docker image is built FROM node:18-bullseye.
Amazon RDS reports that the database in question is an Aurora PostgreSQL version 14.3.
Prisma is version 4.3.0

In my case, downgrading to node 16.17.0 (using node:16-bullseye) works. I did not change anything else!
This is only a short term solution though.

@pingvinen the stack trace looks very similar to the one posted earlier in this issue. Any chance you could send the core dump as well if there is no sensitive information in it?

Everything works locally and in our CI, but as soon as the code is deployed to AWS ECS (fargate), then it explodes in a fiery segfault :)
Amazon RDS reports that the database in question is an Aurora PostgreSQL version 14.3.

Are you using a local PostgreSQL instance during development and in CI, or is it Amazon RDS too?

Any chance you could send the core dump

I would love to, but I did not get one :(

Are you using a local PostgreSQL instance during development and in CI, or is it Amazon RDS too?

Locally and in the CI, I am using postgres in a docker container - specifically postgres:14.3-alpine.
And the code that segfaults is the exact same docker image that is booted up in AWS, as I build the production image and boot it up to run tests against it.

Locally and in the CI, I am using postgres in a docker container

Thank you, this is very valuable information actually.

I would love to, but I did not get one :(

No worries. Just don't share it via public channels if you manage to get one later if it comes from the production environment — sorry if this is obvious, just wanted to point this out just in case.
I'll try to reproduce it on Monday with the information we now have.

FWIW we are having the same issue.

Reproduction

Create a cloud PostgreSQL database. I used Amazon RDS PostgreSQL 14.3 and Supabase.

Create a minimal Prisma project. I used the following (but it doesn’t matter — you can reuse whatever test project you have):
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id    Int    @id
  login String @unique
}

import { PrismaClient } from '@prisma/client'

async function main() {
  const client = new PrismaClient()

  const results = await client.user.findMany()
  console.log(results)
}

void main()

Run it on x86-64 Debian 11 with Node.js 17+.4.

Process crashes with segmentation fault

❗Note: the segfault is not reproducible on the same Debian version with exact same versions of all packages when using Node.js 16 or on ARM64.

Run ulimit -c unlimited beforehand if necessary if you want to get the core dump.

Here’s the full backtrace with symbols: (click to expand)
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5ca8a5c143 in SSL_get_peer_certificate () from /lib/x86_64-linux-gnu/libssl.so.1.1
[Current thread is 1 (Thread 0x7f5c987b2700 (LWP 1182))]
(gdb) bt
#0  0x00007f5ca8a5c143 in SSL_get_peer_certificate () from /lib/x86_64-linux-gnu/libssl.so.1.1
#1  0x00007f5c99c518e7 in openssl::ssl::SslRef::peer_certificate ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#2  0x00007f5c9982292d in native_tls::imp::TlsStream<S>::tls_server_end_point ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#3  0x00007f5c999a9b05 in <postgres_native_tls::TlsStream<S> as tokio_postgres::tls::TlsStream>::channel_binding ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#4  0x00007f5c999302f6 in <tokio_postgres::maybe_tls_stream::MaybeTlsStream<S,T> as tokio_postgres::tls::TlsStream>::channel_binding () from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#5  0x00007f5c99846d54 in tokio_postgres::connect_raw::connect_raw::{{closure}} ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#6  0x00007f5c998bd6e1 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#7  0x00007f5c99996e7f in <tokio::time::timeout::Timeout<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#8  0x00007f5c998cfeef in <quaint::pooled::manager::QuaintManager as mobc::Manager>::connect::{{closure}} ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#9  0x00007f5c99886280 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#10 0x00007f5c992bb06e in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#11 0x00007f5c992ad399 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#12 0x00007f5c9923f9a5 in mobc::time::timeout::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h87d7ad478931b0ea ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#13 0x00007f5c992446a3 in <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#14 0x00007f5c992cb97f in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#15 0x00007f5c992c4643 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#16 0x00007f5c992ac990 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#17 0x00007f5c98cc572d in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#18 0x00007f5c98cfbf35 in <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#19 0x00007f5c98ca1535 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#20 0x00007f5c98cb476d in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#21 0x00007f5c98c983c6 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#22 0x00007f5c98c2534d in tokio::runtime::task::harness::poll_future ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#23 0x00007f5c98c2be3e in tokio::runtime::task::harness::Harness<T,S>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#24 0x00007f5c99c33025 in std::thread::local::LocalKey<T>::with ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#25 0x00007f5c99c23693 in tokio::runtime::thread_pool::worker::Context::run_task ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#26 0x00007f5c99c22b9e in tokio::runtime::thread_pool::worker::Context::run ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#27 0x00007f5c99c34ae7 in tokio::macros::scoped_tls::ScopedKey<T>::set ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#28 0x00007f5c99c225bb in tokio::runtime::thread_pool::worker::run ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
--Type <RET> for more, q to quit, c to continue without paging--
#29 0x00007f5c99c39d21 in <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#30 0x00007f5c99c44a29 in tokio::runtime::task::harness::Harness<T,S>::poll ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#31 0x00007f5c99c28e6a in tokio::runtime::blocking::pool::Inner::run ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#32 0x00007f5c99c37ac2 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#33 0x00007f5c99c3b14f in core::ops::function::FnOnce::call_once{{vtable-shim}} ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#34 0x00007f5c99f028d3 in alloc::boxed::{impl#44}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/alloc/src/boxed.rs:1872
#35 alloc::boxed::{impl#44}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> ()
    at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/alloc/src/boxed.rs:1872
#36 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#37 0x00007f5cab4c3ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#38 0x00007f5cab3e3aef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95k

And here’s the relevant part:
#0  0x00007f5ca8a5c143 in SSL_get_peer_certificate () from /lib/x86_64-linux-gnu/libssl.so.1.1
#1  0x00007f5c99c518e7 in openssl::ssl::SslRef::peer_certificate ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#2  0x00007f5c9982292d in native_tls::imp::TlsStream<S>::tls_server_end_point ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#3  0x00007f5c999a9b05 in <postgres_native_tls::TlsStream<S> as tokio_postgres::tls::TlsStream>::channel_binding ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#4  0x00007f5c999302f6 in <tokio_postgres::maybe_tls_stream::MaybeTlsStream<S,T> as tokio_postgres::tls::TlsStream>::channel_binding () from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#5  0x00007f5c99846d54 in tokio_postgres::connect_raw::connect_raw::{{closure}} ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#8  0x00007f5c998cfeef in <quaint::pooled::manager::QuaintManager as mobc::Manager>::connect::{{closure}} ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
#12 0x00007f5c9923f9a5 in mobc::time::timeout::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h87d7ad478931b0ea ()
   from /home/aqrln/repro/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node

Immediate Cause
Whether the issue is reproducible depends on Node.js version: on the same system the reproduction script succeeds on Node.js 16.17.0 and older, but crashes with segmentation fault on Node.js 17.0.0 or newer.
Git bisect shows that the specific commit in Node.js that starts failing is https://github.com/nodejs/node/commit/66da32c045035cf2710a48773dc6f55f00e20c40.
This means that somehow the issue is triggered due to Node.js itself using bundled OpenSSL 3.0 and us using system OpenSSL, which in this case is 1.1.1n.
The specific instruction where it crashes inside OpenSSL:
(gdb) p $rip
$1 = (void (*)()) 0x7f5ca8a5c143 <SSL_get_peer_certificate+19>
(gdb) disassemble
Dump of assembler code for function SSL_get_peer_certificate:
   0x00007f5ca8a5c130 <+0>:     push   %r12
   0x00007f5ca8a5c132 <+2>:     test   %rdi,%rdi
   0x00007f5ca8a5c135 <+5>:     je     0x7f5ca8a5c160 <SSL_get_peer_certificate+48>
   0x00007f5ca8a5c137 <+7>:     mov    0x510(%rdi),%r12
   0x00007f5ca8a5c13e <+14>:    test   %r12,%r12
   0x00007f5ca8a5c141 <+17>:    je     0x7f5ca8a5c158 <SSL_get_peer_certificate+40>
=> 0x00007f5ca8a5c143 <+19>:    mov    0x1b8(%r12),%r12
   0x00007f5ca8a5c14b <+27>:    test   %r12,%r12
   0x00007f5ca8a5c14e <+30>:    je     0x7f5ca8a5c158 <SSL_get_peer_certificate+40>
   0x00007f5ca8a5c150 <+32>:    mov    %r12,%rdi
   0x00007f5ca8a5c153 <+35>:    call   0x7f5ca8a423b0 <X509_up_ref@plt>
   0x00007f5ca8a5c158 <+40>:    mov    %r12,%rax
   0x00007f5ca8a5c15b <+43>:    pop    %r12
   0x00007f5ca8a5c15d <+45>:    ret
   0x00007f5ca8a5c15e <+46>:    xchg   %ax,%ax
   0x00007f5ca8a5c160 <+48>:    xor    %r12d,%r12d
   0x00007f5ca8a5c163 <+51>:    mov    %r12,%rax
   0x00007f5ca8a5c166 <+54>:    pop    %r12
   0x00007f5ca8a5c168 <+56>:    ret
End of assembler dump.

The source code of the function:
X509 *SSL_get_peer_certificate(const SSL *s)
{
    X509 *r;

    if ((s == NULL) || (s->session == NULL))
        r = NULL;
    else
        r = s->session->peer;

    if (r == NULL)
        return r;

    X509_up_ref(r);

    return r;
}

In other words, the segfault happens due to the ->peer access on the r = s->session->peer line.
Note that s and s->session are checked for NULL right before. That means that either the offset to the peer field is incorrect and points outside the struct, or s->session pointer itself is incorrect, just not NULL.
Let’s check s->session value:
(gdb) p/x $r12
$8 = 0xffffffff

This indeed looks wrong: the value is oddly specific (looks like it came from some int that was equal to -1) and is definitely outside the heap (for comparison, s is 0x7f5c88003330).

Running this on ARM64 and putting a breakpoint there, you can see that the pointer looks normal, so it doesn’t just work “accidentally”, the bug indeed doesn’t occur on that platform.
(gdb) disassemble
Dump of assembler code for function SSL_get_peer_certificate:
   0x0000ffffe65f5bc8 <+0>:     stp     x29, x30, [sp, #-32]!
   0x0000ffffe65f5bcc <+4>:     mov     x29, sp
   0x0000ffffe65f5bd0 <+8>:     str     x19, [sp, #16]
   0x0000ffffe65f5bd4 <+12>:    cbz     x0, 0xffffe65f5c00 <SSL_get_peer_certificate+56>
   0x0000ffffe65f5bd8 <+16>:    ldr     x0, [x0, #1296]
   0x0000ffffe65f5bdc <+20>:    cbz     x0, 0xffffe65f5c00 <SSL_get_peer_certificate+56>
   0x0000ffffe65f5be0 <+24>:    ldr     x19, [x0, #440]
=> 0x0000ffffe65f5be4 <+28>:    cbz     x19, 0xffffe65f5bf0 <SSL_get_peer_certificate+40>
   0x0000ffffe65f5be8 <+32>:    mov     x0, x19
   0x0000ffffe65f5bec <+36>:    bl      0xffffe66c8f48 <X509_up_ref>
   0x0000ffffe65f5bf0 <+40>:    mov     x0, x19
   0x0000ffffe65f5bf4 <+44>:    ldr     x19, [sp, #16]
   0x0000ffffe65f5bf8 <+48>:    ldp     x29, x30, [sp], #32
   0x0000ffffe65f5bfc <+52>:    ret
   0x0000ffffe65f5c00 <+56>:    mov     x19, #0x0                       // #0
   0x0000ffffe65f5c04 <+60>:    b       0xffffe65f5bf0 <SSL_get_peer_certificate+40>
End of assembler dump.
(gdb) p/x $x0
$1 = 0xffffd40152c0
(gdb) p/x $x19
$2 = 0xffffd400f210

Duplicate issues

https://github.com/prisma/prisma/issues/14122
https://github.com/prisma/prisma/issues/13478

Internal document
https://www.notion.so/prismaio/Segmentation-fault-with-cloud-PostgreSQL-b1b34ba631c44e9e9031f0cf63bcb23f

While we are looking for the best way to fix or prevent the underlying problem, the recommended workaround for affected users is to make sure that the versions of OpenSSL used by Node.js and the system OpenSSL match:

either by downgrading Node.js to 16.x,
or by upgrading the operating system (or Docker image) to use OpenSSL 3 — this might be less suitable for production systems, but this is a good option for those who only encounter the issue on their local machines during development.

Alternatively, if you can't do that and you need to stay with Node.js 18 on a system with OpenSSL 1.1.x, you can switch to the binary engine in Prisma.

Some additional details from newly added duplicate issues:

In https://github.com/prisma/prisma/issues/13641 @maximm98 reported the issue on RHEL (Rocky Linux 8). They say for them the issue started happening only after upgrading from Node.js 18.1.0 to Node.js 18.3.0, but I can't reproduce it working with 18.1.0 — for me it crashes too.

In https://github.com/prisma/prisma/issues/15052 @garth reported that the issue happens with PostgreSQL 14, but not with PostgreSQL 12. I haven't try reproducing it, but it sounds like an interesting detail. Although it's also possible that v12 was self-hosted and v14 is in cloud — the report doesn't include that information.

FYI: If your distribution provides a build of Node.js 18 with OpenSSL 1.1.x, you can use that instead of the upstream Node.js build that vendors OpenSSL 3. This is the case on Alpine, where you can install nodejs-current from repository community: it provides (at the moment of writing) Node.js 18.6.0 linked with OpenSSL 1.1.1q, and the issue is not reproducible when using it.
(added this to the post above as well)

I have bumped into error Command failed with signal "SIGSEGV". today.
I was using node:18-alpine. Changing to node:16-alpine fixed the problem. Thanks @aqrln!
Just out of curiosity-what would I need to change to in order to get it working with node 18?

Just deployed my app first time yesterday. Had the exact same issue as described here, literally tried everything before finding this thread. Fixed it by downgrading node:18 in my Dockerfile to node:16.18.0
With node:18 going into active LTS 6 days ago, stuff will hit the fan in here real soon I believe 😂
My setup was:

DB: PSQL on Supabase

Node: node:18 downgrade to node:16.18.0

NestJS

"prisma": "^3.15.2"

Production: DigitalOcean droplet with image: Ubuntu Docker 19.03.12 on Ubuntu 20.04

Local: M1 MacBook (had to adapt Dockerfile and prisma.schema's binaryTargets to make it work on M1, doesn't affect prod)

@ferdiamg

Local: M1 MacBook (had to adapt Dockerfile and prisma.schema's binaryTargets to make it work on M1, doesn't affect prod)

could you please share your prisma.schema's binaryTargets config?

@ferdiamg

Local: M1 MacBook (had to adapt Dockerfile and prisma.schema's binaryTargets to make it work on M1, doesn't affect prod)

could you please share your prisma.schema's binaryTargets config?

Sure thing
binaryTargets = ["native", "linux-musl"]
and adding OpenSSL to your Dockerfile
RUN apt-get update && apt-get install -y openssl
Issue mentioned here: https://github.com/prisma/prisma/issues/8478#issuecomment-1095544159

Does anyone know how to upgrade OpenSSL on Debian bullseye 11?

I just had the same SEGFAULT problem on my machine, may (or may not) be related to me upgrading to PostgreSQL 15.
Here is the stacktrace, as reported by segfault-handler:
PID 14784 received SIGSEGV for address: 0x1000001b7
/home/clement/Projets/Nota/node_modules/.pnpm/segfault-handler@1.3.0/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x372d)[0x7fbc9854972d]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7fbc9c769520]
/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_get_peer_certificate+0x17)[0x7fbc984be6f7]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x562648)[0x7fb773362648]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x5a60dd)[0x7fb7733a60dd]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x5a2b18)[0x7fb7733a2b18]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x63f295)[0x7fb77343f295]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x842935)[0x7fb773642935]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x83e609)[0x7fb77363e609]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x83e4cf)[0x7fb77363e4cf]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x875b84)[0x7fb773675b84]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x8b1f2c)[0x7fb7736b1f2c]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x875e60)[0x7fb773675e60]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x8b35e3)[0x7fb7736b35e3]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x12ba40)[0x7fb772f2ba40]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0xfa63c)[0x7fb772efa63c]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x90a413)[0x7fb77370a413]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x914aaa)[0x7fb773714aaa]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x90945a)[0x7fb77370945a]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x908ddc)[0x7fb773708ddc]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x90cf64)[0x7fb77370cf64]
/home/clement/Projets/Nota/node_modules/.pnpm/@prisma+client@4.9.0_prisma@4.9.0/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node(+0x8f2af5)[0x7fb7736f2af5]
/lib/x86_64-linux-gnu/libc.so.6(+0x94b43)[0x7fbc9c7bbb43]
/lib/x86_64-linux-gnu/libc.so.6(+0x126a00)[0x7fbc9c84da00]

Environment infos: Node.js v19.4.0, Prisma v4.9.0, PostgreSQL v15.1, Ubuntu v22.04.1
Running on WSL 2 with latest updates (just checked) <IP_ADDRESS>, kernel <IP_ADDRESS>. Windows 11 version 10.0.22621.1105.

Try downgrading to node v16 and see if that fixes anything.

Try downgrading to node v16 and see if that fixes anything.

Afraid that didn't work, segfaults persist.
~(Does seem to be ok with the binary engine though. Monitoring.)~
Still getting errors with the binary engine – same as noted in my first comment.

Thanks for trying. I thought it was related to node18 relying on OpenSSL 3. I used node-segfault-handler to get a stack trace and identified the problem as happening within a library call to OpenSSL. Downgrading to node16 seems to have fixed our problem. If you aren't already then I would recommend something like node-segfault-handler so that you, too, can obtain a stacktrace indicating the failure mode.

You have to compare the openssl version of your os with the version packaged in node. If there is a major version difference, the segfault will happen. So you can only try to upgrade your operating system to have openssl 3, if you don't want to downgrade node.

If you're trying to run this inside the standard node:18 docker image then it's not enough to just do:
apt update && apt install -y openssl

because the system includes<EMAIL_ADDRESS>by default.
One way to get around this is to use node:18-alpine which does not come with openssl installed out of the box. Then you can run:
apk update && apk add openssl

This will make the system use<EMAIL_ADDRESS>which will then mean that when the Prisma database client dynamically links to it, the right version is available. Et voila, no more segfault 😄
Seems like the real issue here is that the Prisma database engine binary and Node binary link to openssl in different ways which can cause version mismatches?
TLDR;
✅
FROM node:18-alpine

RUN apk update && apk add openssl
# do your thing ...

❌
FROM node:18

RUN apt update && apt install -y openssl

If you're trying to run this inside the standard node:18 docker image then it's not enough to just do:
apt update && apt install -y openssl

because the system includes<EMAIL_ADDRESS>by default.
One way to get around this is to use node:18-alpine which does not come with openssl installed out of the box. Then you can run:
apk update && apk add openssl

This will make the system use<EMAIL_ADDRESS>which will then mean that when the Prisma database client dynamically links to it, the right version is available. Et voila, no more segfault 😄
Seems like the real issue here is that the Prisma database engine binary and Node binary link to openssl in different ways which can cause version mismatches?
TLDR;
✅
FROM node:18-alpine

RUN apk update && apk add openssl
# do your thing ...

❌
FROM node:18

RUN apt update && apt install -y openssl
# do your thing...

If you're trying to run this inside the standard node:18 docker image then it's not enough to just do:
apt update && apt install -y openssl

because the system includes<EMAIL_ADDRESS>by default.
One way to get around this is to use node:18-alpine which does not come with openssl installed out of the box. Then you can run:
apk update && apk add openssl

This will make the system use<EMAIL_ADDRESS>which will then mean that when the Prisma database client dynamically links to it, the right version is available. Et voila, no more segfault 😄
Seems like the real issue here is that the Prisma database engine binary and Node binary link to openssl in different ways which can cause version mismatches?
TLDR;
✅
FROM node:18-alpine

RUN apk update && apk add openssl
# do your thing ...

❌
FROM node:18

RUN apt update && apt install -y openssl
# do your thing...

I added openSSL 3.0.x to my ubuntu 20.04 image but Prisma is still segfaulting for me.
This is what I did in my container
RUN export echo "deb http://archive.ubuntu.com/ubuntu/ jammy main restricted" >> /etc/apt/sources.list \
    && apt update \
    && apt -y remove openssl \
    && apt -y install openssl

When I run prisma version it's still running version 1.1.x:
prisma                  : 4.10.1
@prisma/client          : 4.10.1
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine aead147aa326ccb985dcfed5b065b4fdabd44b19 (at node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli aead147aa326ccb985dcfed5b065b4fdabd44b19 (at node_modules/.pnpm/@prisma+engines<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.10.1-1.80b351cc7c06d352abe81be19b8a89e9c6b7c110
Default Engines Hash    : aead147aa326ccb985dcfed5b065b4fdabd44b19
Studio                  : 0.481.0

In my node_modules/prisma folder I can also see two binaries which are only for 1.1.x and nothing for 3.0.x:
libquery_engine-debian-openssl-1.1.x.so.node
query-engine-debian-openssl-1.1.x
Anybody have a workaround?

@billysheppard2022 Are you sure you're running<EMAIL_ADDRESS>on the system? A lot of the time just apt install openssl won't get you up to<EMAIL_ADDRESS>because apt might not have the latest version.
For reference, when I run this:
FROM node:18

RUN apt update \
    && apt remove openssl -y \
    && apt install openssl -y

# Check OpenSSL version
RUN apt list openssl

# Check Prisma version
RUN npm i -g prisma
RUN prisma version

I get:
Step 3/5 : RUN apt list openssl
 ---> Running in 1c3fc47f863d

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Listing...
openssl/stable-security,now 1.1.1n-0+deb11u4 arm64 [installed]

and:
Step 5/5 : RUN prisma version
 ---> Running in 832ca0e7c706
prisma                  : 4.10.1
@prisma/client          : Not found
Current platform        : linux-arm64-openssl-1.1.x
Query Engine (Node-API) : libquery-engine aead147aa326ccb985dcfed5b065b4fdabd44b19 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli aead147aa326ccb985dcfed5b065b4fdabd44b19 (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.10.1-1.80b351cc7c06d352abe81be19b8a89e9c6b7c110
Default Engines Hash    : aead147aa326ccb985dcfed5b065b4fdabd44b19
Studio                  : 0.481.0

I think I found the PR that broke it? Maybe? https://github.com/prisma/prisma-engines/pull/3243/files

I have similar problem when application is exiting with code 139:
We are building alpine image with latest prisma version (4.10.1) and running application based on this image. When any prisma method is called, application fails with 139 code. Strangely, this happens only when we build image on Mac with M1, when we run same thing in github jobs (linux), then there is no problem.
More details about set up:

docker file looks similar to:

FROM node:16-alpine
RUN apk add --no-cache libc6-compat openssl
RUN yarn  install
RUN yarn db:generate
RUN yarn build
....

prisma version:

prisma                  : 4.10.1
@prisma/client          : 4.10.1
Current platform        : linux-musl-arm64-openssl-3.0.x
Query Engine (Node-API) : libquery-engine aead147aa326ccb985dcfed5b065b4fdabd44b19 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli aead147aa326ccb985dcfed5b065b4fdabd44b19 (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.10.1-1.80b351cc7c06d352abe81be19b8a89e9c6b7c110
Default Engines Hash    : aead147aa326ccb985dcfed5b065b4fdabd44b19
Studio                  : 0.481.0

Do you have any idea what can cause that?

Here is a Dockerfile in case you want to continue using node:19.x.x:
FROM node:19.1.0 AS runner
# add testing repository to sources
RUN echo "deb http://deb.debian.org/debian testing main" >> /etc/apt/sources.list
RUN apt-get update && apt-get install -y openssl && openssl version

I'm running this on a Fedora 36 Toolbox

Getting segfaults as well with the new prisma version 4.10.1 - we're running node:16.16-alpine3.16 - previously had to custom build an image using 4.8.1

I was having the same issue of segmentation fault, interesting thing was, I was able to access db using prisma studio but not with prisma client, solved it by downgrading to node v16 from v18

I'm using Ubuntu, and I was able to make it work by downgrading to v16. But this needs to be fixed.

After struggling for an hour or two, it worked after changing engineType to binary. Thank you very much.

engineType = "binary" // add this

This works form me too. Using nvm to change from node 19 to 16. Works now

Downgrading the node version to 16 from 18 worked for me. It didn't matter whether I set the engineType to binary or not. It worked in both cases. However, it didn't work in node v18, even with binary engineType. I am using PopOs 22.04

For me the error changed when I engineType to binary.
PrismaClientKnownRequestError:
realty-internal-api | Invalid `prisma.propertyClassification.findMany()` invocation

This only occurred on side by side query is runing like:
Promise.all([
  prisma.query1.findMany(),
  prisma.query2.findMany()
]);

// SIGSEGV when engineType is `library` and `PrismaClientKnownRequestError` when is `binary`.

// No problem when:
await  prisma.query1.findMany();
await  prisma.query2.findMany();

But during multiples request, even without Promise.all still happens. Maybe it is a concurrently problem.
Just in alpine, in a full image (FROM node:18) of node it is ok.

Just to add on here:
We are running in Cloud Run with Cloud SQL. We had a number of issues using the generally documented CloudSQL volume mounts to connect our Cloud Run instances to our database.
Switching to the IP address method in our DB Connection strings would cause our applications to segfault immediately.
The fix we found worked was to add sslmode=disable when using direct IP addresses in our connection strings, and that seems to have resolved our issues. Just in case this helps anyone else who is having issues with Prisma and CloudRun/CloudSQL.
We didn't attempt any of the experiments above to change our binary type, or our nodejs version.

same issue here, I use prisma v4.10.1 with node v19.5.0, downgrading to v16.19.1 is work for me

I had this issue running Kubuntu 22.10 and was able to get prisma to recognize OpenSSL 3 only by removing /usr/lib/x86_64-linux-gnu/libssl.so.1.1. It looks like the generate command just takes the first libssl found, regardless of what the system OpenSSL version is or what the latest version is.
Here's the relevant excerpt from DEBUG=* npx prisma generate:
  prisma:get-platform  Trying platform-specific paths for "debian" (and "ubuntu") +0ms
  prisma:get-platform  Command "ls -v "libssl.so.0*" /usr/lib/x86_64-linux-gnu | grep libssl.so | grep -v "libssl.so.0"" successfully returned "libssl.so
libssl.so.1.1
libssl.so.3
" +14ms
  prisma:get-platform  Found libssl.so file using platform-specific paths: libssl.so
libssl.so.1.1
libssl.so.3
 +0ms
  prisma:get-platform  The parsed libssl version is: 1.1.x +0ms

Hi everyone! Could you check if updating prisma and @prisma/client to 4.12.0-integration-rtld-deepbind.3 fixes the issue for you? It does in the cases that I tested, but it would be very helpful to test this on more different systems.
This is an experimental dev version not intended for production but if it works as expected, we'll work on making this land in a stable release. Thank you!

@aqrln I tested this and it works:
(node 18, debian bullseye, hosted postgres DB, prisma 4.11.0) => error with segfault on connect

(node 18, debian bullseye, hosted postgres DB, prisma 4.12.0-integration-rtld-deepbind.3) => successful connection

@aqrln Fixed here too 💯 same configuration as @mmachatschek

@aqrln This works for me as well!
Node 18, Ubuntu 20.04 on Windows (WSL2), hosted PostgreSQL database (on GCP)
prisma and @prisma/client version 4.9 => Segmentation Fault:

prisma and @prisma/client version 4.12.0-integration-rtld-deepbind.3 => works perfectly!:

I hope you get the PR merged soon!

I'm having similar issue. But I can't create a reproducible case, it only happens when running our whole application. I can only recreate it on ARM64 machine and not on AMD64 which is strange.
I have tried the new testing version, but it doesn't fix my issue. More information can be found in the following slack thread https://prisma.slack.com/archives/CA491RJH0/p1679654874088859

I managed to fix my issue to go from ubuntu:22.04 to Debian:stable which changes ssl version from 3 on ubuntu to 1 on Debian. Is there some issue with arm64+prisma+openssl3?

I use arm64 Ubuntu 22.10 also get Segmentation fault (core dumped) error.
% npx prisma version
prisma                  : 4.10.1
@prisma/client          : 4.10.1
Current platform        : linux-arm64-openssl-3.0.x
Query Engine (Node-API) : libquery-engine aead147aa326ccb985dcfed5b065b4fdabd44b19 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli aead147aa326ccb985dcfed5b065b4fdabd44b19 (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.10.1-1.80b351cc7c06d352abe81be19b8a89e9c6b7c110
Default Engines Hash    : aead147aa326ccb985dcfed5b065b4fdabd44b19
Studio                  : 0.481.0
Preview Features        : orderByNulls, filteredRelationCount

% uname -a
Linux ubuntu 5.19.0-1019-oracle #22-Ubuntu SMP Thu Mar 9 02:32:24 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

% lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 22.10
Release:        22.10
Codename:       kinetic

I can't create a reproducible case, the problem I encountered when running the https://github.com/civitai/civitai project, here's the full log for reference:

npm run dev
><EMAIL_ADDRESS>dev
> next dev

ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000
info  - Loaded env from /home/ubuntu/Projects/GitHub/Civitai/civitai/.env
warn  - You have enabled experimental features (largePageDataBytes, modularizeImports) in next.config.mjs.
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.

event - compiled client and server successfully in 7.8s (4341 modules)
wait  - compiling / (client and server)...
event - compiled client and server successfully in 2.9s (4582 modules)
wait  - compiling /src/middleware (client and server)...
event - compiled successfully in 72 ms (41 modules)
wait  - compiling /api/auth/[...nextauth] (client and server)...
event - compiled successfully in 306 ms (562 modules)
prisma:query SELECT "public"."Tag"."id", "public"."Tag"."name", "public"."Tag"."isCategory" FROM "public"."Tag" LEFT JOIN "public"."TagRank" AS "orderby_1_TagRank" ON ("public"."Tag"."id" = "orderby_1_TagRank"."tagId") WHERE ("public"."Tag"."target" && $1 AND "public"."Tag"."id" NOT IN ($2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$40,$41,$42,$43,$44,$45,$46,$47,$48,$49,$50,$51,$52,$53,$54,$55,$56,$57,$58,$59,$60,$61,$62,$63,$64,$65,$66,$67,$68,$69,$70,$71) AND ("public"."Tag"."id") NOT IN (SELECT "t0"."id" FROM "public"."Tag" AS "t0" INNER JOIN "public"."TagsOnTags" AS "j0" ON ("j0"."toTagId") = ("t0"."id") WHERE ("j0"."fromTagId" IN ($72,$73,$74,$75,$76,$77,$78,$79,$80,$81,$82,$83,$84,$85,$86,$87,$88,$89,$90,$91,$92,$93,$94,$95,$96,$97,$98,$99,$100,$101,$102,$103,$104,$105,$106,$107,$108,$109,$110,$111,$112,$113,$114,$115,$116,$117,$118,$119,$120,$121,$122,$123,$124,$125,$126,$127,$128,$129,$130,$131,$132,$133,$134,$135,$136,$137,$138,$139,$140,$141) AND "t0"."id" IS NOT NULL)) AND "public"."Tag"."unlisted" = $142) ORDER BY "orderby_1_TagRank"."modelCountAllTimeRank" ASC LIMIT $143 OFFSET $144
prisma:query SELECT COUNT(*) FROM (SELECT "public"."Tag"."id" FROM "public"."Tag" WHERE ("public"."Tag"."target" && $1 AND "public"."Tag"."id" NOT IN ($2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$40,$41,$42,$43,$44,$45,$46,$47,$48,$49,$50,$51,$52,$53,$54,$55,$56,$57,$58,$59,$60,$61,$62,$63,$64,$65,$66,$67,$68,$69,$70,$71) AND ("public"."Tag"."id") NOT IN (SELECT "t0"."id" FROM "public"."Tag" AS "t0" INNER JOIN "public"."TagsOnTags" AS "j0" ON ("j0"."toTagId") = ("t0"."id") WHERE ("j0"."fromTagId" IN ($72,$73,$74,$75,$76,$77,$78,$79,$80,$81,$82,$83,$84,$85,$86,$87,$88,$89,$90,$91,$92,$93,$94,$95,$96,$97,$98,$99,$100,$101,$102,$103,$104,$105,$106,$107,$108,$109,$110,$111,$112,$113,$114,$115,$116,$117,$118,$119,$120,$121,$122,$123,$124,$125,$126,$127,$128,$129,$130,$131,$132,$133,$134,$135,$136,$137,$138,$139,$140,$141) AND "t0"."id" IS NOT NULL)) AND "public"."Tag"."unlisted" = $142) OFFSET $143) AS "sub"
wait  - compiling /api/trpc/[trpc] (client and server)...
event - compiled successfully in 822 ms (562 modules)
prisma:query SELECT 1
prisma:query SELECT "public"."Announcement"."id", "public"."Announcement"."title", "public"."Announcement"."content", "public"."Announcement"."color", "public"."Announcement"."emoji" FROM "public"."Announcement" WHERE ("public"."Announcement"."id" NOT IN ($1) AND ("public"."Announcement"."startsAt" <= $2 OR "public"."Announcement"."startsAt" IS NULL) AND ("public"."Announcement"."endsAt" >= $3 OR "public"."Announcement"."endsAt" IS NULL)) ORDER BY "public"."Announcement"."id" DESC LIMIT $4 OFFSET $5
Segmentation fault (core dumped)

@onepunchcat looking at your prisma -v output, you’re on 4.12.0-integration-views-fs.1 and not 4.12.0-integration-rtld-deepbind.3, could you please try again with 4.12.0-integration-rtld-deepbind.3?
Make sure to use an exact version in package.json without a ^ in the beginning so that the package manager won’t grab something unrelated that was published under the integration tag later.

@onepunchcat although on the second thought, given ARM and OpenSSL 3, this looks like a completely different bug, so this patch won’t really help indeed. Could you please open a new issue so we can take a look? Thanks!
@mentos1386 same for you, it looks like the same issue as @onepunchcat has but different from this GitHub issue. I’ll take a look at the linked thread in a bit.

@aqrln I create a new issue #18510

@onepunchcat thank you!

Also had this issue on prisma 4.12.0. Switching over to binary engine in the client fixed it for now. Would love to use the default library, but not super important as of now :)
Thanks for looking into this, I saw that a change was potentially in flight already.
Node version: v18.15.0
Prisma version: v4.12.0

Hey guys, also faced this Segmentation Fault when trying to connect to a Neon db inside a Github action. Using 4.12.0-integration-rtld-deepbind.3 version fixed it ✅ .

Same for me:
Running npm i<EMAIL_ADDRESS>did the trick!

Downgrading Node version from 18.0.0 to 16.0.0 fixed for me.
It's sad that i had to downgrade, but atleast, i have more time to try to fix it better. Thank you guys

@AlexandreSenpai @conjohnerton Please do try https://github.com/prisma/prisma/issues/10649#issuecomment-1480051566 and let us know if this works for you.

it is Today, after many hours with no issues, 4.12.0-integration-rtld-deepbind.3 stopped to be a solution to the problem: the SEGFAULT error is showing up again.
Anything I can do to help find the cause, please ask away.

@andreasciamanna could you please post the full output of prisma -v, which platform you are on, and what kind of database are you using?

@aqrln
Environment variables loaded from .env
prisma                  : 4.12.0-integration-rtld-deepbind.3
@prisma/client          : 4.12.0-integration-rtld-deepbind.3
Current platform        : debian-openssl-3.0.x
Query Engine (Node-API) : libquery-engine 3b9f029aeb9a91829e6648c61146b02f3646d1e7 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 3b9f029aeb9a91829e6648c61146b02f3646d1e7 (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.12.0-22.3b9f029aeb9a91829e6648c61146b02f3646d1e7
Default Engines Hash    : 3b9f029aeb9a91829e6648c61146b02f3646d1e7
Studio                  : 0.483.0

About the other things, see #47416

Hi, I'm having the same issue. Here is my prisma -v output:
prisma                  : 4.12.0
@prisma/client          : 4.12.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7 (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.12.0-67.659ef412370fa3b41cd7bf6e94587c1dfb7f67e7
Default Engines Hash    : 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7
Studio                  : 0.483.0

I'm running it on an Ubuntu 22.04.2 LTS.

Experiencing seg faults once running Ubuntu server 22 on a raspberry pi 4 and using the latest prisma (4.12). Downgrading to prisma 4.0 fixed it for me.

@sarink the new ARM problem is a different issue from this one, could you please leave a comment in https://github.com/prisma/prisma/pull/18426?

(just a heads up that the link was wrong in the previous comment in case you are reading it in email notifications and not in GitHub UI, updated it https://github.com/prisma/prisma/issues/18510)

Hi, I'm having the same issue. Here is my prisma -v output:
prisma                  : 4.12.0
@prisma/client          : 4.12.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7 (at<EMAIL_ADDRESS>Format Wasm             : @prisma/prisma-fmt-wasm 4.12.0-67.659ef412370fa3b41cd7bf6e94587c1dfb7f67e7
Default Engines Hash    : 659ef412370fa3b41cd7bf6e94587c1dfb7f67e7
Studio                  : 0.483.0

I'm running it on an Ubuntu 22.04.2 LTS.

Installing the following version temporarily solved it for me:
npm install --save-dev<EMAIL_ADDRESS>npm install --save<EMAIL_ADDRESS>

This issue is fixed in Prisma 4.13.0 which will be released tomorrow, on Tuesday, Apr 18. If you need to temporarily use a pre-release version until then, you can use 4.13.0-dev.33.
Note that this GitHub issue is about a specific bug that occurs when using Node.js 17+ on a system with OpenSSL 1.1 on x86-64 CPUs when using TLS to connect to database. Please do not post comments here if you encounter a segfault under different circumstances, and open a new issue instead!
If you are facing segfaults on ARM, please leave a comment in https://github.com/prisma/prisma/issues/18510 or open a new issue.

@mrsufgi Can you please open a new issue for the configuration where something went wrong for you, which you could fix by removing openssl1.1-compat from your container? That should not be happening and we want to take a deeper look. Thanks.

@janpio that actually sounds expected: if openssl1.1-compat was present in the container, we'd detect the platform as musl and use OpenSSL 1.1, so this issue would occur. Without openssl1.1-compat we'd detect the platform as musl-openssl-3.0.x and use OpenSSL 3.0, so the issue wouldn't occur as the OpenSSL we'd use would be ABI compatible with one provided by Node.js. So no need to open a new issue since it's exactly the same issue.

I've spent many hours trying to figure out why Prisma is segfaulting in the query engine, have tried changing the engine format to "engine" but without any promising result unfortunately.

Prisma
5.0.0

Platform
Dockerized through MacOS M1 (ARM)

NodeJS
18.17.0

I tried playing around with different versions and found that node 18.16 and above has this problem, from what I can tell node version 18.15 is the latest version that runs without encountering any segfault. Worth noting is that the faulty versions did still work for smaller queries but they broke when GraphQL concatenated larger queries which I had a test case for.
So basically this was the workaround I came up with:
# Dockerfile
FROM node:18 -> FROM node:18.15

I just fixed this by using the binary engine instead of the library engine. Will there ever be a proper fix for this?

This error still happens with version 4.15.0. engineType = "binary" does the trick.

We spend almost full day trying to find why was not working until We find this post, We was building our image using node:18.4.0-alpine.
At the end we could fix the problem by decreading the node version to node:18.alpine  thanks! @kylejw2 and @Hampfh

I've just encountered this issue when running my NodeJS app with Prisma on Render.com. Node 22 LTS, Prisma 5.22. Adding engineType = "binary" solved the issue for me.

Same here but changing the engineType didn't solve the issue (Node 22 LTS Prisma 5.22).
I've the db running on a container.

@chinanderm @albibenni could you please open new issues with more info for reproduction (e.g. a Dockerfile)? The specific issue you are commenting on is three years old, fixed long time ago and has regression tests that ensure it doesn't occur again. The problem you are facing is probably very similar (especially if only the Node-API engine is affected) but we still can't investigate it without any context. Posting comments here also spams the inboxes of 62 more people who don't have this problem anymore.


fix: always use https with unpkg

I don't see why you wouldn't use https with unpkg.
When I hit localhost (non-https), I get "Refused to load the script" error.

Hi @mahcloud thanks for the contribution, I guess it makes sense if it's causing issues. Thanks for the PR.


The documents are not up to date and have some errors

Describe the bug
When I was reading it, I found some small details wrong, for example: the name of the repository has been updated, but not in the documentation, as you can see in the image below.

fixed in https://github.com/brain-facens/FieldVision-AI/commit/7ab87506d42954e5414b0f31e1afe4f2bcbb4dc6

Issue fixed in https://github.com/brain-facens/FieldVision-AI/commit/7ab87506d42954e5414b0f31e1afe4f2bcbb4dc6


Move Organization operations to the top-level

This PR moves the Organization operations to their own top-level class in the SDK.
This is a breaking change that will be part of v1.0.0.
Resolves SDK-170.

Codecov Report

Merging #68 (0e64cbc) into master (f0629ff) will increase coverage by 0.22%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #68      +/-   ##
==========================================
+ Coverage   92.22%   92.44%   +0.22%
==========================================
  Files          16       17       +1
  Lines         373      384      +11
==========================================
+ Hits          344      355      +11
  Misses         29       29

Impacted Files
Coverage Δ

workos/organizations.py
100.00% <100.00%> (ø)

workos/portal.py
100.00% <100.00%> (ø)

workos/utils/validation.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f0629ff...0e64cbc. Read the comment docs.


[Request]  Context Menu "Translate this Page".

Hi.  I'm looking for a good Translator for Firefox, and so far I like yours.  The reason why yours is good is because it will reload the same page instead of opening up a new tab.  Then, if I want to revert back to the original language, I can just hit Alt + Left Arrow to go back.  It's almost as good as the built-in translator in Chrome.  For others reading this, I have better luck with Microsoft of Bing Translator as the Google Translator will do annoying things like say "This page is already in English" when it isn't.  Anyway, I don't like moving my mouse to the navigation bar each time I want to translate a page.  I don't even want a button in the navigation button at all.  I want to right click the page and select "Translate this Page".  Can you add a context menu option like that?

PS - Replied to https://github.com/Mathnerd314/page-translator/issues/7 but then closed it.  Thanks for the help!  I hope you add this context menu (right click on page) "Translate this Page" feature soon.  I noticed some similar web extensions that have the context menu thing, so I know it can be done with AMO policies.  The user script you gave me for the alerts worked perfectly.  Thanks!

I'm wondering why the "automatically translate page" option is not sufficient? That is 0 clicks and hence the most efficient UI.

Because I only want to translate when I want to translate.  Not have the webpages automatically do stuff.  Much like the Chrome browser does.  You have to initiate the process.  Why not make it an "option" and not a default, so those who prefer having context menu can have it.  And those who don't want that in their UI can not have it.  I don't know why are you are being so stubborn about it.  Either you want a good web extension, or you don't.  And if you don't... well I'm disappointed.  Other web extensions have it, so why don't you?  The ONLY reason why I've picked your webs extension over "Dictionary (Google™ Translate) Anywhere" is because theirs does have the context menu OPTION, but they always open up translated pages in new tabs instead of the same one.  So both your web extensions have flaws, much to my chagrin.  Maybe I need to learn how to reverse engineer this stuff and just make my own that does what it should.

I mean by your logic, you should 100% take away the option to put the translate button in the URL bar because >>>>> the "automatic translate page" option is sufficient enough, it would be 0 clicks, and the most efficient UI.
Get real.

Thanks for your help.  There were some flaws with https://addons.mozilla.org/en-US/firefox/addon/page-translator-revised/, but I created GitHub issues and he fixed them all within a day or two.  His extension now does everything that I want and what your extension won't, adding the OPTIONS (that one can turn on/off).    Although disappointed, I am eternally grateful for the userul information you shared earlier and for providing a user script that removes the iframe warning popups.  You are a good guy.  Just too close minded and stubborn.

You are a good guy.

Anyways the context menu option is implemented now.

Cool.  I wasn't expecting that.  I will give it a try.  Thanks.

Okay, your extension could potentially be better than the other one I was using for one reason.  If you want to cancel the translation, you only have to hit the back button once and you will see the original page again.  On the other guy's extension, you have to hit the back button twice.
However, I'm disappointed.  I explicitly asked you to make it "Translate this Page" (first letter of first word capitalized, first letter of second letter not capitalized, and first letter of last word capitalized) but you made it "Translate Page" instead.  If you insist on "Translate Page" and won't change it, I don't think I can make the switch.  Even though I will have to hit the back button twice on his extension, at least his context menu text is nicer.
Thanks for the effort, and once again I won't hold my breath.  But maybe you will surprise me again.

Are you sure "this" should be lowercase? It is capitalized in "Bookmark This Page" and "Edit This Bookmark":
https://searchfox.org/mozilla-central/rev/662de518b1686c4769320d6b8825ce4864c4eda0/browser/locales/en-US/chrome/browser/browser.dtd#186

Yes, I am sure.  I know in Firefox, every context menu havs the first letter of every word capitalized.  And I know by English standards, almost every word that is four letters or more will have the first letter capitalized if it is a title or the name of a menu option.  But I also know that it will look much better with a lowercase t on This.  And it looks better to be inconsistent from Firefox's method than to be consistent with it.  For one, other extensions do not follow the pattern.  I have uBlock installed and it says "Block element" and not "Block Element".  So you are going to get lowercase words, no matter what, if you have at least one extension installed.  I"ve seen "Translate ... (sic)" written different ways in different extensions, so I've had time to see what looks best.  And a lowercase t looks best.  I promise you that "Translate this Page" is wayyyyyyy better than "Translate This Page".  So hopefully you just trust me on that.  I mean the other extension I am using has "Translate with Bing" and not "Translate With Bing".  And it has "Translate with Google" and not "Translate With Google".  So I'm not a crazy person here.  The important words are the first word "Translate" and the last word, which is "Google", "Bing", or "Page".  The middle word "With" is not an important word and should not stand out or detract.  On a side note, I doubt that you want to do this, but you can also make it an Option where the user can choose how it shows up in the context menu.  One of the extensions that I tried, I forgot which one, let you manually type what you want to show up in the context menu.  I can't remember which extension it was, but here is one that lets you manually type what you want a certain Google image 'View Image' button text will look like - https://addons.mozilla.org/en-US/firefox/addon/view-image/  I think that will be going far and beyond what you need to do because "Translate this Page" is perfect.  I would start with "Translate this Page" and then later, one day in the far future, if you feel like getting nerdy you can add more (but unnecessary) customization options.  It would be a good experience and make your extension look more polished, but it would be totally unnecessary.  Although, if you do later acquire that knowledge and experience, you could add the custom context menu text option to other web extensions you develop.  So there is that.  But yep, 100%, don't need it now and "Translate this Page" is what you need.


Adequacy of NAS proteome prediction outside of cancer studies.

Hi,
I am currently analysing a human transcriptome (both RNA-seq + miRNA-seq) dataset from myometrium samples for which paired proteomic data will be acquired v. soon. I was looking for approaches to predict proteome from transcriptome data and just came accross the NAS transcriptome-proteome preprint, which looks very interesting and I am keen to try on our data.
Is there any reason why this model shouldnt be applicable to non-cancer datasets?
If this seems feasible, what is the best way to get started? I was thinking of maybe using a NAS model trained on CPTAC to predict a proteome and then compare it with the real measurements. Do the codes provided in https://github.com/xomicsdatascience/RnaToProteinDataModule support external datasets easily?
Gonçalo

Hi @Gscorreia89! Thank you for your interest!
This model can definitely be applied to non-cancer datasets. In fact, when we were starting the project, we actually played around with including Alzheimer's Disease (AD) datasets, though ultimately we opted to stick to CPTAC data. However, the framework has been put in place to allow more datasets.
What we did was create a class called Dataset (found in src/RnaToProteinDataModule/Dataset.py) that can be extended to specific data types. We made two child classes, CptacDataset and AdDataset, from this class. The idea is that, provided the correct functions are implemented in the child classes, then the NAS model can load the data in a consistent way regardless of the data source.
Generally when implementing a child class of Dataset, the following should be kept in mind:

You will need to include loading the proteome and transcriptome values in the init function. These should ultimately be pandas dataframes, where indices refer to IDs and column names refer to proteins/transcripts.
There are two main abstract functions you will need to implement, match_patient_ids_between_omic_layers and deal_with_isoforms. The first ensures that the proteome/transcriptome share all their IDs, the latter indicates what should be done with identified isoforms.

That is a quick introduction, but I'd be happy to help work through making a child class for a new dataset.
Some extra info:
Datasets are processed in the DatasetProcessor class to synchronize them between each other before loading them into the NAS (for example, making sure the proteins are shared between proteome datasets etc.). See the prepare_data function for the process by which these are called.
I should also note the existence of the DatasetSplitter classes. In a nutshell, how you perform and normalize the train/validation split can change depending on the program you are trying to run. In the case of the DataProcessor instance used in the NAS, a train:val split of 90:10 is used (StandardDataSplitter). Other options include not splitting the data at all (NoSplitJustNormalizer), something you may want to do for additive datasets to your training, should your target dataset be too small for adequate training alone. The FiveByTwoDataSplitter class is specific to running a five by two cross validation experiment, and is not used in an NAS.

Thanks for your interest @Gscorreia89.
It should also be noted that you will need at least hundreds of paired proteome/transcriptomes from the same samples to train models from scratch. Better would be at least 1000 pairs. If this scale is not possible, you could alternatively tune the model with part of your data. Note that tuning would require complete overlap in the measured transcripts.

Hi @CCranney and @jessegmeyerlab,
Thanks for the quick and detailed reply. I don't have those numbers, and what I had in mind is to simply use the "best model" trained as per your instructions and examples on CPTAC data to obtain a prediction that I can compare when the proteome data is acquired.
Btw, what type of computational resources do you require/suggest to fit the NAS model on CPTAC as per your examples?

Do you mean for running the NAS itself, or for the optimal model that we found by using the NAS? If the former, we ran it on our HPC GPU using 40-50GB. That was likely overkill, but better to overshoot than undershoot in those instances.

@CCranney thanks for sharing the HPC script header with the resource info. I will have a go first at using the NAS best model on my samples and get back to you if I run into any issues at this stage.


Blog post republishing - The journey of documenting a Socket.IO API

Hello AsyncAPI folks! Raising this issue to suggest the re-publishing of my series of blog posts wrt Socket.IO and AsyncAPI.
Post title
The journey of documenting a Socket.IO API (Pt 1)
The journey of documenting a Socket.IO API (Pt 2)
Post description
How to document your Socket.IO API? This is a series of blog posts covering the modelling of the Socket.IO protocol using AsyncAPI objects followed by a step-by-step tutorial on how to create a specification YAML file given an existing Socket.IO API.
The series of article is already published on my personal blog:
https://dedouss.is/posts/2021-06-24-documenting-socketio-part-1.html
https://dedouss.is/posts/2021-07-14-documenting-socketio-part-2.html

I saw the content already! please republish, one by one of course, with some time difference. Do you need guidance? here you have source of last blog post, to see how the metadata should be filled and what is needed. I'd like to also push forward, from next/this article that we make sure we have alt text for each image to make content inclusive for people that cannot see images.

Both blog posts have been published. Thanks a lot for your help @derberg and @alequetzalli!


app crashes

on click of ok button app crashes. can anyone suggest me what can be the problem

I suppose it's about the Android sample?
Better discuss first in forum with more information, like the exception log.

Please include a step by step guide what you did, including the GH version and Android version.

i simply run this graphhopper android sample example . it is showing europe cities. can anyone tell me how could i add some other country names to list so as to download their maps in this app


Small typo in update.go

Not really worth a fork and a PR, update.go line 91 => line should read:
fmt.Printf(green("Successfully updated to version v%s"), latestVersion)

These errors are easy to catch when running staticcheck in one of the actions.

Hello @mobilarte,
Thank you for your input, it helps us a lot.
FYI, you can open pull-requests without having to fork the repository first, straight from the github website. Just click the pencil icon at the top-right corner of the file (link).
To be clear, I am not saying that you should have done that; in fact, after all our PR fixes other issues raised by staticcheck and adds it as a Github action. I just thought you would like to know.


oauth problems with latest bits

I'm using your latest bits, Ubuntu 20.04.2 LTS and go1.15.8
I had a bit of "fun" setting up (I had to add the localhost:7979 URrIL in two places (Authorized JavaScript origins, and Authorized redirect URIs).
$ ./nesthub -setup
Please open https://nestservices.google.com/partnerconnections/7fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx06/auth?redirect_uri=http://localhost:7979&access_type=offline&prompt=consent&client_id=98xxxxxxxx43-gdxxxxxxxxxxxxxxxxxxxxxxxxxxxxh9.apps.googleusercontent.com&response_type=code&scope=https://www.googleapis.com/auth/sdm.service in browser
2021/02/06 01:57:28 Authorization successful.
2021/02/06 01:57:28 oauth2: cannot fetch token: 400 Bad Request
Response: {
"error": "invalid_request",
"error_description": "Missing required parameter: code"
}
The redirect was ...
http://localhost:7979/code=4/0AxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxmA&scope=https:/www.googleapis.com/auth/sdm.service

Thanks for this. I ran the setup on MacOS and only needed to add the redirect to Authorized redirect URIs. I'll be setting this up on a linux distro shortly and should be able to see that setup flow.

Sorry for the late reply. I've tried the setup with the latest release v1.2.1 on NixOS 22.05 and haven't had any issues.
nesthub -setup
2022/08/25 01:40:54 Enabling Smart Device Management API
2022/08/25 01:40:56 Waiting for the Smart Device Management API to be enabled...
Please open https://nestservices.google.com/partnerconnections/ba...8c/auth?redirect_uri=http://localhost:7979&access_type=offline&prompt=consent&client_id=36...kc.apps.googleusercontent.com&response_type=code&scope=https://www.googleapis.com/auth/sdm.service in browser
2022/08/25 01:41:16 Authorization successful. 4/...lw
...

Closing. Please let me know if you're still running into issues.


C++ getBounds() template error

What's the correct way of using a custom box3f type together with getBounds()? As far as I understand it defining your own type is the only option with the C++ wrappers if you don't want to use rkcommon (which only has source releases, hence is less attractive). I've tried this:
#include <ospray/ospray_cpp.h>

struct vec3f {
    float x, y, z;

    vec3f(): x(0), y(0), z(0) {}
    vec3f(float xx, float yy, float zz): x(xx), y(yy), z(zz) {}
};

struct box3f {
    vec3f   upper, lower;
};

namespace ospray {
OSPTYPEFOR_SPECIALIZATION(vec3f, OSP_VEC3F);
OSPTYPEFOR_SPECIALIZATION(box3f, OSP_BOX3F);
}

int main()
{
    ospray::cpp::Camera c;

    const box3f bounds = c.getBounds();
}

Compiling this snippet results in an error, saying that the return type template parameter of getBounds() can't be determined:
melis@juggle 18:58:~/concepts/ospray-python$ g++ -I ~/software/ospray-2.7.0.x86_64.linux/include/ t_bounds2.cpp
t_bounds2.cpp: In function ‘int main()’:
t_bounds2.cpp:23:37: error: no matching function for call to ‘ospray::cpp::Camera::getBounds()’
   23 |     const box3f bounds = c.getBounds();
      |                          ~~~~~~~~~~~^~
In file included from /home/melis/software/ospray-2.7.0.x86_64.linux/include/ospray/ospray_cpp/Camera.h:6,
                 from /home/melis/software/ospray-2.7.0.x86_64.linux/include/ospray/ospray_cpp.h:8,
                 from t_bounds2.cpp:1:
/home/melis/software/ospray-2.7.0.x86_64.linux/include/ospray/ospray_cpp/ManagedObject.h:44:11: note: candidate: ‘template<class BOX3F_T> BOX3F_T ospray::cpp::ManagedObject<HANDLE_T, TYPE>::getBounds() const [with BOX3F_T = BOX3F_T; HANDLE_T = osp::Camera*; OSPDataType TYPE = OSP_CAMERA]’
   44 |   BOX3F_T getBounds() const;
      |           ^~~~~~~~~
/home/melis/software/ospray-2.7.0.x86_64.linux/include/ospray/ospray_cpp/ManagedObject.h:44:11: note:   template argument deduction/substitution failed:
t_bounds2.cpp:23:37: note:   couldn’t deduce template parameter ‘BOX3F_T’
   23 |     const box3f bounds = c.getBounds();
      |                          ~~~~~~~~~~~^~

My C++ template-fu isn't strong enough to figure out how to fix this...

Hmmm, looking at https://github.com/ospray/ospray/blob/a783bf987cff6a2d70a2dfce6732d7f2572703bd/ospray/common/Instance.cpp#L37-L40 it seems that what I'm trying isn't too unreasonable :smile:

Ah, looking at apps/ospTestSuite/test_geometry.cpp I think I got it:
const box3f bounds = c.getBounds<box3f>();

Yes, that should do the trick (using OSPTYPEFOR_SPECIALIZATION for own types, as done for example in ospray_cpp/ext/glm.h and then forcing the template specialization by explicitly passing the own type as template argument) .


return dependency value

Hi,
is it possible to "inject" somehow the value from a dependency to the  create or update model?
I would like to add the updating user in my create schema.
Any ideas?
Thank you for the great work

Hi @KarlCMB. Thanks for the feedback!
It is possible to do it with a dependency, However, currently I think the easiest way is to provide a custom implementation of the router (see #80). I am actively looking at ways of making the library more injectable; hopefully coming in a future release.


support AE pilot project

per brainstorms on 9/21 and 9/25
context

AE is building a POC of a new app (planning doc in sharepoint)
AE and DE would like to minimize the amount of data engineering performed by AE and implement an ideal AE tech stack

details and ideas

DE is helping with the planning and generating of source data for the app
the planned source data is:

Mapbox Vector Tiles (MVTs) of MapPLUTO and Zoning Districts
a Postgis DB with MapPLUTO

likely want to generate MVTs during the DE Publish stage of a product build

but DE doesn't build Zoning Districts, so should it be considered more of a pull from AE that generates all MVTs?

needs scoping

which zoom levels should the POC MVTs be generate at?
which MapPLUTO and Zoning Districts columns should be in the MVTs?
what data cleaning does AE need (e.g. drop invalid geometries, simplify geometries)?

informed AE that MVTs can and have been pushed to the S3 bucket de-sandbox
will touch base w/ AE about the other desired data (tables with PLUTO data)

per AE, this Carto SQL query is what they currently use to select relevant Pluto fields for MVTs
for efficiency, MVTs should have a minimal number of fields, especially non-categorical fields

Ah I can address that - once we get your little PR merged I'll add something to filter fields

from meeting on 10/10
AE action items

create DE issues with source data specifications

DE action items


[DO NOT MERGE] Update plan-your-setup.md

@DaniHalfin

@DaniHalfin - PR is ready for final review. This is related to the SEO project.
Thank you.

@DaniHalfin can we get this reviewed?

@tuco-ulf - can you follow up on the request above? Thanks 😀

@DaniHalfin looks like I'll have to create another PR to get into this to make the changes - Justin is no longer around to give me permissions.