prisma: 4.16.1 breaks type check

Bug description

This will probably get dismissed because I’m not currently able to strip down from our repository what exactly is causing this. But from 4.16.0 -> 4.16.1 I’m not able to use next build because something on prisma is causing a cyclic type loop that is exhausting v8 memory.

I also noticed that types in some occasions (only happened in one model) stopped working. I can’t go to type definition nor autocomplete. Don’t dismiss it yet, I’m trying to reproduce what’s causing this. I created this bug report in case anyone has the same issue (couldn’t find others) and was able to recreate it in minimal reproduction.

Rolling back to 4.16.0 fixes this issue

An example of the error thrown while type checking:

<--- Last few GCs --->

[1960:00000221C0ABAC30]    85531 ms: Mark-sweep 4048.5 (4136.9) -> 4033.6 (4138.1) MB, 1230.4 / 0.0 ms  (average mu = 0.094, current mu = 0.025) allocation failure scavenge might not succeed
[1960:00000221C0ABAC30]    86821 ms: Mark-sweep 4049.6 (4138.1) -> 4034.9 (4139.4) MB, 1236.3 / 0.0 ms  (average mu = 0.068, current mu = 0.042) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
- info Linting and checking validity of types . 1: 00007FF6F615B34F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+123599
 2: 00007FF6F60E8CB6 v8::internal::MicrotaskQueue::GetMicrotasksScopeDepth+65206
 3: 00007FF6F60E9D8D node::OnFatalError+301
 4: 00007FF6F6A1C36E v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF6F6A0694D v8::SharedArrayBuffer::Externalize+781
 6: 00007FF6F68A9F2C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
 7: 00007FF6F68B6BD9 v8::internal::Heap::PublishPendingAllocations+1129
 8: 00007FF6F68B3BAA v8::internal::Heap::PageFlagsAreConsistent+2842
 9: 00007FF6F68A6809 v8::internal::Heap::CollectGarbage+2137
10: 00007FF6F68A49C0 v8::internal::Heap::AllocateExternalBackingStore+2000
11: 00007FF6F68C9546 v8::internal::Factory::NewFillerObject+214
12: 00007FF6F65FBCE5 v8::internal::DateCache::Weekday+1797
13: 00007FF6F6AAA061 v8::internal::SetupIsolateDelegate::SetupHeap+494417
14: 00000221C2DC6AD0
error Command failed with exit code 1.

How to reproduce

Expected behavior

No response

Prisma information


generator client {
    provider = "prisma-client-js"
}

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

Somehow I believe the extends may have something to do with this.

import { PrismaClient } from "@prisma/client"

import { env } from "@/helpers/env.mjs"

import type { Prisma} from "@prisma/client"

type PaginationArgs<Input, Output extends Record<string, any> = {}> = {
	page?: number;
	limit?: number;
	sort?: "asc" | "desc";
	order?: string;

	map?: (data: Input) => Output | Promise<Output>;
}

function getPrisma () {
	return (new PrismaClient({
		log: env.NODE_ENV === "development" ? ["error", "warn"] : ["error"],
	})).$extends({
		name: "paginate",
		model: {
			$allModels: {
				async paginate<
					T,
					Args,
					Result extends Prisma.Result<T, Args, "findMany">,
					Options extends PaginationArgs<Result[number]>,
				>(this: T, args: Prisma.Exact<Args, Omit<Prisma.Args<T, "findMany">, "cursor" | "take" | "skip">> & Options) {
					const { page = 1, limit = 25, select, where, order, sort } = (args || {}) as any

					return Promise.all([
						(this as any).findMany({
							select,
							where,
							skip: (page - 1) * limit,
							take: limit,
							...(order ? { orderBy: { [order]: sort || "asc" } } : {}),
						}).then(function (result: any) {
							return args.map ? Promise.all(result.map(args.map)) : result
						}),
						(this as any).aggregate({
							_count: { id: true },
							take: limit,
							select: { _count: true },
							where,
							skip: (page - 1) * limit,
						}).then((response: any) => ({
							page,
							pages: Math.ceil(response._count.id / limit),
							total: response._count.id,
							limit,
						})),
					]) as Promise<[
						Options["map"] extends Function ? Awaited<ReturnType<Options["map"]>>[] : Result,
						{ page: number; pages: number; total: number; limit: number },
					]>
				},
			},
		},
	})
}

const globalForPrisma = globalThis as unknown as { prisma: ReturnType<typeof getPrisma> }

export const prisma =
	globalForPrisma.prisma || getPrisma()

if (env.NODE_ENV !== "production") globalForPrisma.prisma = prisma

Environment & setup

OS: Windows 10
Database: PostgreSQL
Node.js version: v16.17.1

Prisma Version

prisma                  : 4.16.1
@prisma/client          : 4.16.1
Current platform        : windows
Query Engine (Node-API) : libquery-engine b20ead4d3ab9e78ac112966e242ded703f4a052c (at node_modules\@prisma\engines\query_engine-windows.dll.node)    
Migration Engine        : migration-engine-cli b20ead4d3ab9e78ac112966e242ded703f4a052c (at node_modules\@prisma\engines\migration-engine-windows.exe)
Format Wasm             : @prisma/prisma-fmt-wasm 4.16.0-66.b20ead4d3ab9e78ac112966e242ded703f4a052c
Default Engines Hash    : b20ead4d3ab9e78ac112966e242ded703f4a052c
Studio                  : 0.484.0

About this issue

Original URL
State: closed
Created a year ago
Reactions: 15
Comments: 38 (16 by maintainers)

Most upvoted comments

Thanks for your reproduction @TarsiSurdi, I can confirm that your project can now compile with the fix I have shared.

millsp on Jul 21, 2023

I had the same problem, and @prisma/client @5.1.0-integration-fix-client-oom-default-selection.3 fixes it for me. Thanks!

chunkerchunker on Jul 11, 2023

I’m also experiencing similar issues with Typescript when trying to annotate a method of a repository in a NestJS app using 4.16.x.

When annotating the method and it’s parameter with these (from PrismaClient):

My LSP immediately stops working and doesn’t come back even after restarting;
Nest is unable to compile but keeps on trying until the it errors with a memory leak similar to OP’s.

However, downgrading to 4.15.0 fixes all of these issues because the types generated by the ORM are different (they do not include <ExtArgs>), so maybe it could be something related to that 🤔

TarsiSurdi on Jul 5, 2023

@millsp seems to be working

5.1.0-integration-fix-client-oom-default-selection.3:

with v5 I get error in the id property

luisrudge on Jul 21, 2023

@millsp I couldn’t test it yet because I didn’t find time to upgrade to v5. We just migrated from mongo+mongoose to prisma+pgsql at work 😅 so I didn’t want to risk the migration with a major upgrade. I’ll try to find some time next week.

luisrudge on Jul 21, 2023

For NestJS users: you will notice that we have a breaking change in Prisma 5, with beforeExit not existing anymore. You should be able to remove the enableShutdownHooks which is documented in NestJS’ docs. If you need to emit queries before the shutdown, you should now use the standard NestJS way of doing it (eg. via beforeApplicationShutdown). We will work in the coming days to update the docs, you can track our process here: https://github.com/prisma/prisma/issues/20171

millsp on Jul 12, 2023

Same issue here, VSCode dies from tsserver.js getting caught in an infinite loop. I am using extensions to add a computed property to a model. If I remove the computed property, things return to normal. Still, it seems types with extensions are generally very finicky, as this is not the only instance I’m running into this issue when I’m trying to type extensions with NestJS safely.

It’s probably worth noting that all of us appear to be using NestJS as well, so I’m sure that also plays a part with typing, as we cannot define types properly for extensions without proxy/factory trickery.

jasonmacdonald on Jul 11, 2023

This appears to be exactly what I am doing as well. I am glad someone is facing this in a public repository. Thank you @TarsiSurdi!

JoeyEamigh on Jul 5, 2023

@millsp Of course I can! Here is the repository for the personal project I’ve been developing where this bug is present: fincheck-api

Please note that I’ve set the Prisma version to be 4.15.0 in package.json so my project doesn’t show this behavior!

The issue caused by the type annotations of the findMany method inside of the BankAccountRepository class necessary for proper TypeScript/InteliSense when using it inside the BankAccountsService class as described in this image:

EDIT: I should clarify that the reason for the type annotations of that particular method (generics in findMany) is different that the others present in the repository is so that TypeScript is able to compile the BankAccountService’s code since it uses{includes: ...} on it’s query. If you don’t annotate it like that, proper types are not infered for what is present in the Transaction entity.

EDIT: I’ve tested multiple version of TypeScript (including 5.x.x) and Node.js. The issue persists.

Steps to reproduce bug

Clone the repository and set up a PostgreSQL database along with the necessary environment variables documented in the .env.example file.
Before running yarn install, make sure you change the Prisma version to one of the affected by this issue and then install dependencies.
(Not sure if it’s necessary) Run yarn prisma generate.
Try to annotate the affected method BankAccountsRepository.findMany so it’s signature matches the types present on the Prisma Client generated types.
Watch your TypeScript LSP die, have Nest.js to be stuck compiling until it crashes due to a memory leak of sorts…

TarsiSurdi on Jul 5, 2023

Just encountered the same problem, but interestingly enough, it’s only happening in 4.16.2. Downgrading to 4.16.1 fixes the problem.

The local build will have a memory leak until it crashes, and CI on Vercel crashes too with the same errors shared above.

I’ve got two similar Next.js projects and only one has the problem ; each one using typescript 5.1.6.

I can send you my prisma schemas if it’s useful (would just prefer not doing it publicly here).

benjaminwaterlot on Jul 3, 2023

I cannot seem to make a simple reproduction, unfortunately. The issue seems to be very specific to how Prisma is being used, because I have two identical Nest.js projects in my monorepo, each importing Prisma from the same prisma.service.ts file, and the issue only occurs in one of the projects. The other project is able to build perfectly fine.

I have run some tsc profiling on identical projects, one running 4.15.0 and the other running 4.16.2. Hopefully these are somewhat helpful.

successful builds:

prisma                  : 4.15.0
@prisma/client          : 4.15.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 8fbc245156db7124f997f4cecdd8d1219e360944 (at ../../node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 8fbc245156db7124f997f4cecdd8d1219e360944 (at ../../node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Format Wasm             : @prisma/prisma-fmt-wasm 4.15.0-28.8fbc245156db7124f997f4cecdd8d1219e360944
Default Engines Hash    : 8fbc245156db7124f997f4cecdd8d1219e360944
Studio                  : 0.484.0
Preview Features        : fullTextSearch

failing builds:

prisma                  : 4.16.2
@prisma/client          : 4.16.2
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 4bc8b6e1b66cb932731fb1bdbbc550d1e010de81 (at ../../node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 4bc8b6e1b66cb932731fb1bdbbc550d1e010de81 (at ../../node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Format Wasm             : @prisma/prisma-fmt-wasm 4.16.1-1.4bc8b6e1b66cb932731fb1bdbbc550d1e010de81
Default Engines Hash    : 4bc8b6e1b66cb932731fb1bdbbc550d1e010de81
Studio                  : 0.484.0
Preview Features        : fullTextSearch

the rest of the projects are identical. the attached trace files can be thrown into https://ui.perfetto.dev/, and the resolutions.txt file is just the stdout and stderr of the following command:

NODE_OPTIONS='--max-old-space-size=61440' yarn tsc --traceResolution -p apps/api/tsconfig.app.json --generateTrace dist/debug --incremental false 2>&1 | tee ./dist/debug/resolutions.txt

4.15.0-trace.json.txt - success ~4s 4.15.0-resolutions.txt - success ~4s

4.16.2-trace.json.txt - fail ~70s 4.16.2-resolutions.txt - fail ~70s

Can probably remove the Next.js tag since this is also happening with Nest.js (these two are too closely named lol). I wish I could be more helpful than this, but tsc is proving to be a bit of a black box for debugging without any internal knowledge.

JoeyEamigh on Jul 2, 2023

@darklight9811 Prisma version 4.16.2 is now available, based on what you said it’s unlikely that it fixes your issue, but we’re interested to get an update on your problem. So if you could share what’s the problem / error now (might be different). That would be great!

Also like my colleague said, please let us know which TypeScript version you are using, 5.1 has some known issues that should be fixed in 5.1.5 now.

Jolg42 on Jun 30, 2023

@darklight9811 which Typescript version are you on? There was a bug in TS compiler 5.1.x that was fixed in 5.1.5. Could you try updating to 5.1.5 and see if it fixes this problem.

SevInf on Jun 30, 2023

@Jolg42

4.16.2-dev.2 removed all type properties from the methods 4.17.0-integration-client-extensions-fluent-api.1 fixed it but still breaks next type checking process

I installed everything, rerun prisma generate and restarted ts server (vscode)

darklight9811 on Jun 30, 2023