text:
Cannot extend types on inheriting classes

I have a class that extends EventEmitter. I have added type support on that event emitter and everything works pretty well:
// BaseClass.ts
import EventEmitter from "eventemitter3";

type EventTypes = {
  foo: () => void;
  bar: (error: Error) => void;
};

export default class extends EventEmitter<EventTypes> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
  }
}

Problems start when I try to extend that class, and the child class needs to emit some extra events. To support that type of functionality I had to add generics on my previous class
// BaseClass.ts
import EventEmitter from "eventemitter3";

type EventTypes = {
  foo: () => void;
  bar: (error: Error) => void;
};

export default class<T extends object> extends EventEmitter<EventTypes & T> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
  }
}

and my ChildClass:
// ChildClass.ts
import BaseClass from "./BaseClass";

type ExtraTypes = {
  baz: () => void;
};

export default class extends BaseClass<ExtraTypes> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
    this.emit("baz");
  }
}

While ChildClass is OK, TS compiler starts complaining on BaseClass on every emit generating the following error:

Argument of type '"foo"' is not assignable to parameter of type 'EventNames<EventTypes & T>'

I am not sure if this is a weakness in TS, eventemitter3's type system or something wrong in my code but how can I bypass the problem?
Codesanbox link: https://codesandbox.io/s/pedantic-drake-d73tv

Hey @antoniom, I’m having the same issue. Did you find a solution?

@alexryd I actually ended up implementing my own on* callbacks and using different instances of EventEmitter on each class. It turned out that I never had to emit a parent event from my child class.
Something like this:
// BaseClass.ts
import EventEmitter from "eventemitter3";

type EventTypes = {
  foo: () => void;
  bar: (error: Error) => void;
};

export default class {
  private _ee: EventEmitter<EventTypes> = new EventEmitter();
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
  }

  public onFoo = (func: EventTypes["foo"]) => this._ee.on("foo", func)
  public onBar = (func: EventTypes["foo"]) => this._ee.on("bar", func)
}

// ChildClass.ts
import BaseClass from "./BaseClass";

type ExtraTypes = {
  baz: () => void;
};

export default class extends BaseClass {
  private _ee: EventEmitter<ExtraTypes> = new EventEmitter();
  constructor() {
    super();
  }
}

I'm in exactly the same position. Not sure if it's a limitation of TypeScript or of this library.

Same here, still trying some workarounds

I wish I would have discovered this issue reported a while ago, but then I may not have discovered my final (for-now) resolution.
The 2 remaining issues I have:

Emitting from within the class that extends EventEmitter
An interface extending EventEmitter does not properly restrict to MyTypes event names

Both issues are detailed here.
Hopefully it helps!
Cheers!

Anyone found a solution to this?

This worked for me:
// BaseClass.ts

import EventEmitter from "eventemitter3";

export interface EventTypes {
  foo: () => void;
  bar: (error: Error) => void;
}

export class BaseClass<T extends EventTypes> extends EventEmitter<EventTypes | T> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
  }
}

// ChildClass.ts

import { BaseClass, EventTypes } from "./BaseClass";

interface ExtraTypes extends EventTypes {
  baz: () => void;
}

export class ChildClass extends BaseClass<ExtraTypes> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
    this.emit("baz");
  }
}

But it feels like a hack. My changes were:

I changed the types to interfaces so that I could extend from one another
T extends EventType instead of T extends object so that I could use EventType | T, instead of &. This works since T extends EventType, but it feels hackish.

This worked for me:
// BaseClass.ts

import EventEmitter from "eventemitter3";

export interface EventTypes {
  foo: () => void;
  bar: (error: Error) => void;
}

export class BaseClass<T extends EventTypes> extends EventEmitter<EventTypes | T> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
  }
}

// ChildClass.ts

import { BaseClass, EventTypes } from "./BaseClass";

interface ExtraTypes extends EventTypes {
  baz: () => void;
}

export class ChildClass extends BaseClass<ExtraTypes> {
  constructor() {
    super();
    this.emit("foo");
    this.emit("bar", new Error("bar"));
    this.emit("baz");
  }
}

Summary of changes:

I changed the types to interfaces so that I could extend from one another
T extends EventType instead of T extends object so that I could use EventType | T, instead of &. This works since T extends EventType, but it feels a bit hackish.

This solution works.!
But further, how to implement multi-level inheritance.
Does anyone have an idea?

authors: AkiraChinUp alexryd antoniom edolix karts-with-freaking-lasers kebian pauloddr sharathprabhal


text:
Is the code of eval_gpt4_longqa.sh is correct?

The code in it seems to be Python code rather than a shell script.

Thanks for catching this, it's been fixed!

source: gharchive/issue

repo: princeton-nlp/HELMET

license: MIT

license_type: permissive

license_source: github-api


text:
the added special tokens seem to convert to ids uncorrectly with my chinese datasets

Have you tried the argument of add_new_tokens? I used bert-base-chinese to train my chinese dataset, and the number of entity types exceeds the total [unused], after applying add_marker_tokens function, the vocab size and tokenizer length both added from 21128 to 21300. Then, I applied the origin BERT model, and applied resize_token_embeddings(), however,  I found that the special token, such as  <subj_start=地点>, <obj_start=人物>, etc, are all represented as 100, namely [UNK] in the sequence of input_ids after applying tokenizer.convert_tokens_to_ids(). Since the different marker tokens should have different id according to the paper, could you please help me to solve this problem?

Yes, our ALBERT experiments are based on add_new_tokens. Did you try just to use tokenizer.tokenize()?

Thanks for your reply!
I used tokenizer.tokenize() to find that the added_tokens.json was not work, it still only use the origin vocab.txt. Thus, I wondered how to use both origin and added tokens to apply the convert_tokens_to_ids() function in your experiment?

Could you please tell me the detailed steps of  ALBERT experiments kindly? Since I find the vocab_size was modified from 30000 to 30046 in rel-alb-ctx0.zip, I have tried to modify the vocab.txt and config.json, also applied resize_token_embeddings(), however, the error of dimension mismatch occured.

Hi, I just want to check back and see whether you have resolved the issue.
I don't think you need to re-pretrain the model (we didn't in our ALBERT experiments). You may check this function to see how we augment the vocabulary.

Hi, I also had this problem after trying to train a model with Bert base. Could you please answer me the following questions:

In the paper you also use base Bert to get the results of typed text markers. However, if I understand you correctly, Albert was used?

To add to that, in the code the "add_new_tokens" parameter is set to false per default and only to true for Albert. Why is that? If I understand the code correctly, only if this is set to true, the model will use the typed markers with entity labels and not the unknown token. Shouldn't this be true per default since it's on of the fundamental concept of this model to learn relations as shown in the paper?

Can I just set the add_new_tokens parameter to true when I want to train base Bert (or any other model than albert) with it?

@hero-png Thanks for your questions!

We tried both BERT and ALBERT as the base model in our experiments with typed markers.
For BERT experiments, we directly used the unused tokens in BERT vocabulary ([unused1], [unused2]) as the markers (check this line). For ALBERT experiments, we had to use add_new_tokens  because there aren't pre-defined unused tokens in ALBERT vocabulary.
Yes, you can set add_new_tokens  to be true when training BERT.

Thank you very much for your fast reply!
Do you know if and how the usage of the unused tokens instead of the subj/obj ones influences the relation extraction result?

@a3616001 Thank you very much for your quick reply!

authors: AndDoIt a3616001 hero-png

repo: princeton-nlp/PURE


text:
Docker image not found

When I run the following scripts:
SQL Call  python -m experiments.eval_n_turn \      --data_path ./data/sql/spider/ic_spider_dev.json \     --dialogue_limit 5 \    --env sql \     --image_name docker-env-sql \     --log_dir logs/experiments \      --max_turns 10 \      --policy chat \      --template game_sql \      --model gpt-3.5-turbo      --handicap       --verbose
It throws an exeception that tells me the docker image is not found:
`(intercode) user@ubuntu:~/botao/intercode-master$ python main.py
Traceback (most recent call last):
File "/home/user/botao/intercode-master/main.py", line 11, in
from experiments.policies import (
File "/home/user/botao/intercode-master/experiments/policies.py", line 5, in
from .utils import ACTION_PARSER_MAP, PROMPT_MAP, CompletionGPT, ChatGPT, PalmChat, PalmCompletion, HFChat
File "/home/user/botao/intercode-master/experiments/utils/init.py", line 20, in
from .open_api import (
File "/home/user/botao/intercode-master/experiments/utils/open_api.py", line 13, in
assert(access_token)
AssertionError
(intercode) user@ubuntu:~/botao/intercode-master$ vim experiments/utils/open_api.py
(intercode) user@ubuntu:~/botao/intercode-master$ python main.py
Traceback (most recent call last):
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/api/client.py", line 265, in _raise_for_status
response.raise_for_status()
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/requests/models.py", line 1021, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.43/images/docker-env-sql/json
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/user/botao/intercode-master/main.py", line 215, in
expr_wrapper = ExperimentWrapper(args)
File "/home/user/botao/intercode-master/main.py", line 55, in init
self.env = SqlEnv(image_name=args.image_name,
File "/home/user/botao/intercode-master/intercode/envs/sql/sql_env.py", line 27, in init
super(SqlEnv, self).init(image_name, **kwargs)
File "/home/user/botao/intercode-master/intercode/envs/ic_env.py", line 77, in init
self.container = get_container(self.container_name, self.image_name, **kwargs)
File "/home/user/botao/intercode-master/intercode/utils/utils.py", line 48, in get_container
image = client.images.get(image_name)
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/models/images.py", line 333, in get
return self.prepare_model(self.client.api.inspect_image(name))
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/utils/decorators.py", line 19, in wrapped
return f(self, resource_id, *args, **kwargs)
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/api/image.py", line 251, in inspect_image
return self._result(
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/api/client.py", line 271, in _result
self._raise_for_status(response)
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/api/client.py", line 267, in _raise_for_status
raise create_api_error_from_http_exception(e) from e
File "/home/user/anaconda3/envs/intercode/lib/python3.9/site-packages/docker/errors.py", line 39, in create_api_error_from_http_exception
raise cls(e, response=response, explanation=explanation) from e
docker.errors.ImageNotFound: 404 Client Error for http+docker://localhost/v1.43/images/docker-env-sql/json: Not Found ("No such image: docker-env-sql:latest")`

I ran into this issue as well, the problem for me was that the sql container in setup.sh requires docker compose, so if you don't have that installed, that image isn't created successfully. Installing docker compose and then running just that line from setup.sh resolved that portion (you may then need to add some items to keys.cfg for other errors). I also had to change the command to docker compose -f docker/sql-docker-compose.yml up -d (removing the dash), but this probably depends on how you install the compose plugin and your environment.

repo: princeton-nlp/intercode


text:
feat: support prisma 2 preview 22

closes #609
closes #605

Hi!
This pull request doesn't resolve the issue - prisma/prisma2#1640 now. I tested the latest commit in the branch - feat/prisma-preview-22-support and here still has an error: TypeError: Cannot read property 'map' of undefined. I think this because of the new DMMF format for after argument.
src/publisher.ts:125 Here you should check that inputType has fields or find this type by name in the DMMF input types and get his fields from there.
Thanks!

closes #605

This PR will probably take until next week. I'm not sure what's going on yet and having a hard time with VSCode + TS Language service. We'll get there.

source: gharchive/pull-request

authors: Devlin556 impowski jasonkuhrt

repo: prisma-labs/nexus-prisma


text:
Google Cloud (GCP) Deployment Guide

We don't yet have a GCP deployment guide: https://www.prisma.io/docs/guides/deployment
We've been getting some SSL + GCP issues recently: https://github.com/prisma/prisma/issues/1228
I think people are running the openssl command here: https://www.prisma.io/docs/concepts/database-connectors/mysql#configuring-an-ssl-connection and getting confused that google doesn't trust their certificate.
It'd be good to properly document this.

@matthewmueller
My suggestion would be to add a section in the general deployment docs.
As for the recommendation, based on https://github.com/prisma/prisma/issues/1228#issuecomment-767110358 it seems that the current solution is to add sslaccept=accept_invalid_cert to the connection string. Is that correct?

We're still testing to see if sslaccept=strict does work.
My feeling is that sslaccept=accept_invalid_cert  with a self-signed certificate shouldn't be the default and that we should really recommend they connect with a trusted certificate.
We still need to confirm that this works.

Would be great if @pantharshit00 could confirm this. I haven't written anything yet.

What product of GCP?

We currently don't have plans for adding this to the docs.

authors: 2color janpio matthewmueller ruheni

repo: prisma/docs


text:
Language server cannot correctly report diagnostics for sources containing multibyte characters

Bug description
If a source contains multi-byte characters, Prisma Language Server cannot report diagnostics with correct position.
e.g.
// 📅📅📅📅📅
enum Day {
  Monday
  Tuesday
  Wednesday
  Thursday,
  Friday
  Saturday
  Sunday
}

It must be reported that a problem is in the line Thursday, that is not an enum value definition.
But the problem is reported in a position of  Friday.
While you put a charater 📅 more, the reported position also shift.
How to reproduce

Write prisma schema
Make it invalid
Put multi-byte character before the invalid line.

Expected behavior
The problem is reported in correct position.
Prisma information
// 📅📅📅📅📅
enum Day {
  Monday
  Tuesday
  Wednesday
  Thursday,
  Friday
  Saturday
  Sunday
}

Environment & setup

OS: Arch Linux
Editor: Neovim
Editor version: v0.10.0-dev-344906a

Same issue:
https://github.com/prisma/language-tools/issues/1308

Hey @kyoh86, a PR fixing issues with multibyte characters was part of our 5.16.0 release, can you please confirm if that version resolves this issue for you?
Thank you in advance! 🙏

@Druue Wow! It's fixed! Thanks so much!

Cool, I'll be closing this as complete then :) ✨

repo: prisma/language-tools


text:
delete and deleteMany are not working for models with and without relations

delete does not delete relations even when using @relation(onDelete: CASCADE)
model One {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  FOne      DateTime
  FTwo      Two      @relation(name: "OneToTwo", onDelete: CASCADE)
}

model Two {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  FOne      String   @unique
  FTwo      String
}

When deleting Model One, Model Two is not deleted.

delete does not delete relations even when using @relation(onDelete: CASCADE)

This is expected right now as cascade deletes are not implemented. Right now you can manually edit the schema and set the cascade behviuor to work around this.

Today I ran into another problem. delete and deleteMany are not even working for models without relation

I am unable to reproduce this. I tested the exact same query and it deleted the required records from the database.

So if please try second query again making sure you are properly awaiting the Promises as pointed out by @JasonZStanley. If this is resolved we can close this as a duplicate of #702.

You can close this issue.

repo: prisma/photonjs


text:
Support for composite string in default in the schema level

Problem
We want to create a readable id for one of our data models such as "table_[uuid]".
Suggested solution
Be able to define a composite string in the schema such as:
id             String               @unique @default(["table_", uuid()])
or
id             String               @unique @default("table_" +  uuid())
it would be also nice to create custom types for those composite strings, such as "TableId" that will infer to a Typescript type or regex.
The current Typescript implementation for this will be:
type TableId = ``table_${string}``;
Alternatives
The current alternative is to handle it in js and then send the composite string to the id field.

Do you think your request is adequately covered by https://github.com/prisma/prisma/issues/3391?
If not, maybe add a comment there - and then close this issue? Thanks.

It does, closing this issue, thanks!

authors: KevinEdry janpio

repo: prisma/prisma


text:
Prisma @@index is creating a unique constraint instead of a normal index key

Bug description
I am trying to index one column in my table using the keyword @@index, when I run the migration Prisma instead create another unique constraint on top of that index.
How to reproduce
Create 2 models with an 1-to-N relationship, then index the foreignkey in the child table. Run prisma migrations and you should see a unique constraint. (NB: Use MySQL)
Expected behavior
It should just do as described in the schema and not add anything else not mentioned out of the blue.
Prisma information

model users {
  id                  Int              @id @default(autoincrement())
  Credit              Credit[]

  @@map("users")
}

model Credit {
  id          Int       @id @default(autoincrement())
  userId      Int
  user        users     @relation(fields: [userId], references: [id])

  @@index(fields: [userId], map: "userID")
  @@map("credit")
}

// Add your code using Prisma Client

Environment & setup

OS: Ubuntu
Database: MySQL
Node.js version: 18

Prisma Version
4.13.0

That is highly unlikely, that would have been noticed in the last few years that code has not been changed.
Can you reproduce this behavior and show us the SQL migration that migrate dev creates for this?
You are using a pretty old Prisma version though, can you please upgrade to a more recent first?

@JefferyHus I can not reproduce the issue, neither on Prisma 5.6.0 nor on Prisma 4.13.0 that you reported. Generated SQL does not contain UNIQUE INDEX line unless I add @unique attribute on userId. Are you sure it was not the case when migration file was created?
If you, we'd ask you to provide clean repo where we can see that happening?

I can confirm this to you. I have tried to remove the @@index from that model and it did not drop the index key nor the unique one. I will try to update to latest prisma and test.

Any update here @JefferyHus? It sounds a bit like you are looking at a different schema file than from what is used to create the SQL.

I still have the issue, this must be due to the fact that I had to generate a schema from an existing database then edit the schema afterwards. We can close this issue for now as it might be affecting me alone.

authors: JefferyHus SevInf janpio


text:
AggregateBalance reserved model name

Why is AggregateBalance a reserved name for models?

@cyrus-za
Because if you create a model named Balance, the prisma client will try to generate an AggregateBalance type for aggregateApi which will conflict with AggregateBalance model.

https://github.com/prisma/prisma/blob/c36c1a7a84a5be3fd12522870a2f48cabdb6b833/src/packages/client/src/generation/generateClient.ts
https://github.com/prisma/prisma-engines/blob/b1c5396ac9832eb8481b3c7f36c393ab1747211d/libs/datamodel/core/src/transform/ast_to_dml/reserved_model_names.rs
There you can look at all deny model name list

Thanks. Just a little strange

Valid concern and we will see if we can find a way around this in some way.

@janpio
https://github.com/prisma/prisma/blob/c36c1a7a84a5be3fd12522870a2f48cabdb6b833/src/packages/client/src/generation/generateClient.ts
Aggregate currently on this list and I see Aggregate${modelName} type in my generated prisma client.

Yes, I can confirm this and the writeup @WellFail did is correct. We will need to prefix them as did for ${name}Client.

authors: WellFail cyrus-za janpio pantharshit00


text:
now() as a value for DateTime fields since new Date() may be wrong

Problem

There is no reliable way to update a DateTime field to now(). @default(now()) only works for create.
Assume the db runs on a server with a precise clock, but the query comes from another device (server, browser) whose clock you have no control over.
If you use new Date() to update, it evaluates to this potentially wrong clock which is not in sync with the clock of the db.
This may lead to broken invariants like time intervals that end (new Date()) before they start (now()).
Suggested solution

DateTime could also allow now() as a string literal to pass through to the db (or change to the db's version of now()).
Alternatives

executeRaw
introduce a dummy field to update and rely on @updatedAt, see discussion below - seems like a hack/does not reflect intent.

Additional context

Example in discussion https://github.com/prisma/prisma/discussions/5582.

I'm also very interested in this discussion. It's really important in any context where the API code is not residing in the same server/timezone/place/universe as the DB.
Here, we ended up by using the raw execution alternative solution, like:
prisma.$executeRaw(`UPDATE "Invite" SET "acceptedAt" = CURRENT_TIMESTAMP WHERE "id" = '${invite.id}'`)

This is not elegant in any way. It requires some SQL knowledge that maybe not all the team members have. String manipulation is always more prone to human errors and... Well, why not a Prisma solution?
But the problem is: if we start to accept any string as valid type for date fields, we also break some type checking advantages. Prisma should not accept every string as a valid type for a date field.
So Prisma could provide some kind of constants. Maybe something like:
prisma.invite.update({
  where: { id: invite.id },
  data: { updatedAt: prisma.now }
})

Or a more powerful solution could be allowing a dbgenerated function as a valid type. It would even allow calling DB functions during our create/update operations, like:
prisma.invite.update({
  where: { id: invite.id },
  data: {
    someUuidField: prisma.dbgenerated('gen_random_uuid()'),
    updatedAt: prisma.dbgenerated('now_plus_60_minutes()')
  }
})

Typescript has string literal types, so you'd just have something like Date | "now()" instead of Date.
This could be used for any DB function (as long as codegen is aware of it - idk where your now_plus_60_minutes() should come from).

@vogler it was just an example to highlight that we could write our own database functions and use those, if we could provide any dbgenerated value for create/update Prisma operations.
Of course this exceeds the original problem of providing "now()" as a valid value for Date fields, but I think it could be helpful for more situations if the adopted solution is more flexible.

I know, but that's another issue. My point was that it's not possible to call user-defined functions and be type-safe without also listing those functions (and their type) in the schema.

Any update on this? I think it is fairly common that in most of situations we do want to take the server time as the client time is not trustable.

It's common that the app server would not be the same box / VM as the DB server. The DB server is often the best choice for a stable time base. The difference would often be negligible (for most apps) in a production environment but can be far off in dev-test situations and especially when running the app on the dev's box. Some solution for this plus a short article in the Prisma docs would help devs recognize the issue and do the right thing more often.

Any update?

I have an endpoint that start and stops a synchronized but low-resolution timer, and was surprised to see that Prisma doesn't have a solution for this. Being able to use SQL now() in this context would be exceedingly helpful

Any updates? That should be a basic task for any ORM

+1

+1

It's 2023 and people still think commenting "+1" is appropriate.
No, it's spamming everyone that is subscribed to this issue. Please stop commenting "+1" and simply upvote the issue instead.
Even this comment is meta and spams subscribers, so, sorry about that.

No comments just: this

I don't really want to start a beef with you but you should probably lean on what your profile says and learn how to contribute and behave on the open source community.

Not that I don't like jokes, but even your second comment irritates me with useless notifications. I'll stop commenting now as I don't help with the issue. Thanks for the gif I guess and have a great day!

2024 .. no support for now() .. finally found something more important that geospatial support.  is Prisma fit for production environments?

authors: ErickPetru HermesSantos V-ed acidjazz boemekeld chrisj-back2work jbwc leoyli-headsup sarcastic-verma vogler zenhob


text:
MaxListenersExceededWarning: prisma 2.20.x and above

Summary
When upgrading @prisma/client and prisma from 2.19.0 to 2.20.x or newer, including 2.21.x, six in total "MaxListenersExceededWarning" messages are being logged:

(node:4511) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:4511) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:4511) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:4511) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGUSR2 listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:4511) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 beforeExit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(node:4511) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGUSR1 listeners added to [process]. Use emitter.setMaxListeners() to increase limit

After the initial logs they don't reappear until re-starting our GraphQL server.   Prior to and with versions 2.19.0 this did not happen.
Background
We run our GraphQL Server as a serverless function on Lambda and create it with the apollo-server-lambda.  We are seeing these logs currently in our local development environment where we run the Lambda locally via the serverless-offline plugin as we utilize the serverless framework for our deployment.
Dependency Versions

@prisma/client: 2.20.0 - 2.21.1

nexus-plugin-prisma: 0.34.1

prisma (dev):  2.20.0 - 2.21.1

serverless-offline: 6.6.0

apollo-server-lambda: ^2.19.0

Problem is seen using Node versions 12.19.1 and as of submitting latest 12 release 12.22.1

@smschick thanks for your report! We'll try to reproduce and we'll keep you updated.
Does this happen during development or tests or in production?
I don't think these warnings are a problem = it should not break anything but they are not expected.

What node version are you using @smschick?

@janpio @smschick mentioned

Problem is seen using Node versions 12.19.1 and as of submitting latest 12 release 12.22.1

This should be fixed in 2.21.2 let us know if it's the case, if not, we can reopen this issue.

This should be fixed in 2.21.2 let us know if it's the case, if not, we can reopen this issue.

I can confirm the max listener warnings are gone.   Thank you so much

I'm seeing this issue both in serverless offline and deployed to lambda in Prisma 3.4.  Initializing Prisma Client takes like 1-2 seconds in apollo-server-lambda while it takes like a few milliseconds in apollo-server.  This means if you open apollo studio explorer which polls every second, you quickly get MaxListenersExceeded and a stack overflow

@dborstelmann Interesting, could you create a new issue so can can look at this?

@Jolg42 Just fixed it in deployments.  It was context.callbackWaitsForEmptyEventLoop = false;.  For some reason the latency is still there in offline.  I sent @ryands17 a replication repo, I'll post a new issue if we discover something on the prisma side.  Thanks!

authors: Jolg42 dborstelmann janpio smschick


text:
Introspection documentation could mention --url

Currently https://github.com/prisma/prisma2/blob/master/docs/introspection.md does not mention the --url parameter that can be used to supply a connection string directly instead of needing a filled out schema.prisma file.
Especially for users with an existing database (P1 users or similar), this can be a quick way to see what a Prisma schema file could look like.

Added via https://github.com/prisma/prisma2/pull/1317

authors: janpio nikolasburk


text:
Make QueryIdx public

Hello. Following this issue a lot of people are interested in make the QueryIdx trait public.
By make it public, you will allow to your consumers to write generic code that can abstract the get() or try_get() implementations far beyond the actual implementations, that is monomorphize with some &str or usize those methods over Row.
Would be possible to make a public reexport of the QueryIdx trait?

Sure, it should be an easy PR to do. Do you want to try?

Sure, it should be an easy PR to do. Do you want to try?

Oh, I completly forgot about this one. Isn't this change made yet?

authors: Pyzyryab pimeys

repo: prisma/tiberius