MaxListeners error with Prisma 4.3.1

[goaaron]

Bug description

I have two prisma clients in my nextjs application connecting to separate databases.

I've placed a process.on("warning", (e) => console.warn(e.stack)) and I get the following message:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. Use emitter.setMaxListeners() to increase limit at _addListener (node:events:465:17) at process.addListener (node:events:487:10) at process.once (node:events:531:8) at ExitHooks.installHook (webpack-internal:///(api)/./prisma/generated/client2/runtime/index.js:27027:17) at ExitHooks.install (webpack-internal:///(api)/./prisma/generated/client2/runtime/index.js:26998:14) at new LibraryEngine (webpack-internal:///(api)/./prisma/generated/client2/runtime/index.js:27077:19) at PrismaClient.getEngine (webpack-internal:///(api)/./prisma/generated/client2/runtime/index.js:31495:24) at new PrismaClient (webpack-internal:///(api)/./prisma/generated/client2/runtime/index.js:31467:37) at eval (webpack-internal:///(api)/./lib/prisma.ts:13:20) at Object.(api)/./lib/prisma.ts (/.next/server/pages/api/my_endpoint.js:242:1)

Unclear what the fix is here. I've seen some closed tickets and discussion bringing this issue up, but no resolution.

How to reproduce

Expected behavior

No response

Prisma information

generator client {
    provider = "prisma-client-js"
    output   = "./generated/client2"
}

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


model z {
    a           Int     @id @default(autoincrement())
    b         Int     @default(1)
    c String?
    d       String?
    e  Json?
    f  String?
    g      Int     @default(1)
    h    Int?
}

model y {
    id     BigInt   @id @default(autoincrement())
    status Boolean?
    time   DateTime @default(now()) @db.Timestamp(6)
}

model x {
    id    Int    @id @default(autoincrement())
    name  String
    email String
}
****

import { prisma_secondary } from "../../../lib/prisma";
import { Prisma } from "@prisma/client";


export default async function handle(
  req: NextApiRequest,
  res: NextApiResponse
) {

  let { qs} = req.query ?? "";

  try {
    const resp = await prisma_secondary.$queryRaw(
      Prisma.sql`SELECT * from x`
    );
    ...

    res.status(200).json(resp);
  } catch (e) {
    return res.status(500).send(e);
  }

Environment & setup

• OS: mac and ubuntu
• Database: postgres
• Node.js version: v16.13.0

Prisma Version

4.3.1

[miguelff]

This is being discussed at #6401

Internal note: EventEmitter usages are being changed and will be released in 4.7.0, so this might require specific reproduction on the offending versions.

EventEmitter can be leaking subscribers, or it can also just be that node's implementation (EvenEmitter is platform dependant) assumes that if you have more than 11 subscribers, that's wrong, when indeed it might be correct. See https://stackoverflow.com/questions/50709059/maxlistenersexceededwarning-possible-eventemitter-memory-leak-detected-11-mess.

It can be also possible that the own process.on("warning", (e) => console.warn(e.stack)) which adds a listener to the event emitter, the one causing that limit to be rebased.

Could you please try upgrading node to a newer version and see if the problem persists?

linking this potential problem to the related work done on error logging, which heavily relies on EventEmitter #16226.

[SevInf]

Since 5.0, prisma does not set listeneres for SIGINT anymore.

I was also unable to reproduce the issue on 4.3.1 either. This code:

async function main() {
  const client = new PrismaClient()
  client.$on('beforeExit', () => {})
  await client.$queryRaw`SELECT * FROM User`
  console.log(process.listenerCount('SIGINT'))
}

Logs 1, so there is only one listener set for this signal. My suspicion is that either something else set other 10 listeners and prisma just happened to be the one that triggered the warning or there are multiple different client instances within your app.

Regardless, update to 5.x should either get rid of this warning or reveal real culprit, so I am going to close this issue for now. Feel free to comment if you encounter it on more recent versions.