Typechecking types generated by prisma causes RangeError: Maximum call stack size exceeded

[dansworkaccount]

Bug description

When typechecking the types that are generated by prisma cause an error RangeError: Maximum call stack size exceeded. This error occurs with typechecking with ts-node, or tsc.

How to reproduce

1. Run prisma generate
2. Run tsc --noEmit

Expected behavior

tsc is able to complete without a stack error

Prisma information

The schema has about ~115 models and ~40 enums.

Environment & setup

• OS: Windows
• Database: PostgreSQL
• Node.js version: v16.5.0
  This the environment of my local machine but the error is occurring on other machines and cicd pipeline

Prisma Version

2.19.0

We are currently working on upgrading to the newest version and moving away from the nexus-plugin-prisma

[janpio]

Can you share the schema maybe? That would be best for a reproduction on our side so we can just start debugging vs. first trying to find a reproduciton.

[pantharshit00]

Also, please try again with latest version. 2.19 is bit old now.

[rs-payres]

Hi, I am @dansworkaccount's coworker and can provide some more information. Unfortunately, our codebase is private so we cannot share it here.
We have been using nexus-plugin-prisma and made the decision to remain behind on versions at the time they announced the rewrite because we needed to focus on some other priorities.
Recently we started running into Maximum call stack size exceeded exceptions when type checking. It started out very infrequently happening and has become more frequent over time. I am working on a branch to remove nexus-plugin-prisma now to try to isolate the issue and that branch is now on Prisma version 2.28 + nexus version 1.1.0 and the plugin removed. This branch consistently has the error. Here is an example stack trace:

RangeError: Maximum call stack size exceeded
    at instantiateTypeWithAlias ([redacted]/node_modules/typescript/lib/tsc.js:49263:42)
    at instantiateType ([redacted]/node_modules/typescript/lib/tsc.js:49261:37)
    at getMappedType ([redacted]/node_modules/typescript/lib/tsc.js:48985:63)
    at [redacted]/node_modules/typescript/lib/tsc.js:49238:92
    at Object.map ([redacted]/node_modules/typescript/lib/tsc.js:371:29)
    at getConditionalTypeInstantiation ([redacted]/node_modules/typescript/lib/tsc.js:49238:40)
    at instantiateTypeWorker ([redacted]/node_modules/typescript/lib/tsc.js:49327:24)
    at instantiateTypeWithAlias ([redacted]/node_modules/typescript/lib/tsc.js:49275:26)
    at instantiateType ([redacted]/node_modules/typescript/lib/tsc.js:49261:37)
    at instantiateMappedType ([redacted]/node_modules/typescript/lib/tsc.js:49177:20)

Currently, we are trying to debug tsc to try to get better information on the issue, but that is not something we have experience with before, so it is a difficult process.

If you have any suggestions we would greatly appreciate it.

[rs-payres]

@janpio I was able to put together a private repository with a minimal reproduction using our schema. Is it possible for me to share this with someone on the Prisma team to review? I believe I have narrowed the bug down to an excessively deep type instantiation stack caused by the custom XOR type on a schema of sufficient size, more specifically, with a model with a sufficient number of relationships.

[janpio]

@pantharshit00 can take a look for sure.

Are you sure this is caused by Prisma and not by Nexus by the way?

[rs-payres]

thank you @janpio. Yes I am sure it is Prisma. My reproduction uses the quick start from prisma docs as the frame. It is Prisma 2.28, with my organization's schema and a single function.

@pantharshit00 I have provided access to the repository for you. Please let me know if you have any issues working with it.

To provide some more information, I can share some of the research I have done.

The reason I believe it is related to the XOR type is from debugging tsc and watching the stack grow until blowing with a ton of XOR frames. I looked at the code for that type which references a stack overflow post, which references issue 14094 in the Typescript repository. That led me to issue 23777 in the Typescript repository which sounds very similar.

Let me know if you have any other questions about it.

[LarryYarianTraction]

For what it's worth, we've recently started to encounter this issue also. We are using Prisma 2.21 and do not use Nexus. We use introspection to build our schema from a Postgres DB. The schema has 124 models with many relationships and 15 enum types.

We thought it might be a Node.js compatibility issue so we downgraded to Node 14.4 and that seemed to help for a little while. But we recently added a few more models, with relationships, to our schema and are experiencing this issue with Node 14.4 now, too.

I can share the schema, if needed, but it needs to be treated as sensitive information and made available only to those who have a need to see it.

[rs-payres]

@janpio @pantharshit00 Has anyone at Prisma been able to look into this issue yet? Our schema has grown enough to reach our initial increased stack limit.

[millsp]

Which version of TypeScript are you currently using? Does this work with other versions?

[dansworkaccount]

We are currently using TypeScript version 4.2.4. We have tested the most recent version 4.4.3 and the error is still present

[Jolg42]

This comment from TypeScript repo could help debug what's happening here maybe
microsoft/TypeScript#31538 (comment)

[rs-payres]

Yes, I have looked at a number of TypeScript issues, that one included, to find debugging steps, which is how I came to the conclusion that this particular issue is caused by the XOR implementation. I have a private repo with minimal reproduction and debugging instructions that I invited @pantharshit00 to. I can invite others from the Prisma team as well if that would be helpful, it is using my company's schema so I cannot share it publicly, unfortunately. I would also be happy to share more information on the research I have already done, I have tried to keep the information I have included so far as closely relevant as possible so as not to spam...

[pantharshit00]

Hello @rs-payres

Sorry for the late reply here. I had to take some time off last week and I wasn't able to get back here on time to accept the repository invitation. Can you please send that again 🙏 ?

[Jolg42]

Note: would be interesting to reproduce with TypeScript version v4.5-beta: https://github.com/microsoft/TypeScript/releases/tag/v4.5-beta and see is result is the same.
Notable changes are that the type depth limit was changed from 50 to 100 and Tail-Recursion Elimination on Conditional Types

[Bjoernstjerne]

We get the same issue with prisma 3.2.1 and typescript 4.4.4, switching back to prisma 3.1.1 and typescript 4.2.3 is working.

[rs-payres]

@Jolg42 I tested my reproduction repo last night on the 4.5 beta and it has the same issue. I looked at the PR for tail-recursion type check ejection before and, while it looks related, it doesn't cover this specific scenario because it is not caught by their previous safety measures.

[millsp]

Hey @rs-payres, can you please invite me to your repro?

[Bjoernstjerne]

Can you please contact me for an NDA? We use the same prisma schema for two backends. The smaller ones tsc compiles fine with prisma up to 3.5 but for the larger backend no version higher than 3.1.1 compiles.

[Jolg42]

Hi @Bjoernstjerne could you contact us at [email protected] so we can handle this privately? NDA is no problem of course.

[Nayir]

Hi there, we are experiencing the same issue with typescript 4.4.3 and prisma 3.4.0 when running a seed.ts with ts-node. So we found a little workaround, building the typescript file into seed.js and running it instead of the .ts file. This way we avoid the RangeError: Maximum call stack size exceeded. @Jolg42 Be free to contact me in private for more informations. My schema is private too I can't share it here.

[ile]

This may be a different issue, but I'm getting RangeError: Maximum call stack size exceeded with this model:

type Address {
	address			String
	name			String
	group			Address[]
}

Actually I created that model with a kind of an accident, and it looks very error-prone. Something that would cause an infinite loop. And it did.

[pimmee]

I'm having the same issue. It also seems to be related to the generic Without / XOR types. It's quite hard to debug which type is the culprit as adding breakpoints in the typescript.js file breaks the debugger, but I've at least managed to add try / catch in the typescript.js file with prints to see it was due to Without / XOR.

The generated prisma types in my project is currently ~165000 LOC, and I suspect the following self referential model is the breaking point, as the generated types is very complex and creates an infinite loop:

model Folder {
  id             String   @id @default(cuid())
  createdAt      DateTime @default(now()) @map("created_at")
  updatedAt      DateTime @updatedAt @map("updated_at")
  path           String
  homeId         String   @map("home_id")
  authorId       String?  @map("author_id")
  files          File[]
  home           Home     @relation(fields: [homeId], references: [id], onDelete: Cascade)
  author         User?    @relation(fields: [authorId], references: [id])
  subFolders     Folder[] @relation("FolderToFolder")
  parentFolder   Folder?  @relation("FolderToFolder", fields: [parentFolderId], references: [id], onDelete: Cascade)
  parentFolderId String?  @map("parent_folder_id")

  @@unique([homeId, path])
  @@map("folders")
}

See for example:

I've emailed the full schema.prisma file to [email protected].

Is there any workaround for this?

PS. I'm using Prisma 4.6.1 and have tried upgrading to latest typescript version etc. without success.

Edit:
The problem does not seem to have been caused by my self referential Folder model, as I tried without it and it still crashed when the generated prisma file was exceeding 165000 LOC.

Increasing the node stack size seems to have "fixed" the problem for me. It seems like the generated Prisma types will break a NodeJS Typescript project once it reaches a certain size unless you increase the node stack-size...?

[demipixel]

I'm experiencing this as well. Was causing silent errors in ts-jest which was sadly many hours of debugging :c

I only have 14 models and experience the same issue. Did some debugging of this issue last night and also found that it seems to occur with an XOR, although unclear if that's the actual issue. Increasing stack size does not seem like a long-term solution, and I assume it's slowing down type checking in the meantime.

[millsp]

Hey @demipixel can you please share a reproduction with us?

[demipixel]

I'll see what I can do. I tried extracting just the schema alone and can't seem to replicate, so must be due to how I'm using the types.

[Jolg42]

Is this still reproducible when upgrading to Prisma 5.1.0?

[KevNik]

@Jolg42 yes, the problem still reproducible, i'm currently using this version and still get the error. I'm working in another project that runs both in windows 10 and Debian 12.

[millsp]

@KevNik could you please share a reproduction with us?

[SevInf]

Hey @KevNik ,

Did you get a chance to have a look at @millsp comment? It'd be helpful for us to move your issue forward.

Thank you 🙏

[KevNik]

Sorry for the late response. After some work, i figured it out.

I was trying to save a bigger Json string than the psql could acttaually handle. It was an error object from axios.
I managed to store only de message and now it's working fine.

You can reproduce this just by making a simple axios request and force it to get a error, in my case, the testEndpoint was not online

**schema.prisma**

model example {
    status    String?    @db.VarChar
}

**function that returns the error**
 
async sendStatusTest(statusTestEndpoint) {
        let response

        try {
            response = await request.post(statusTestEndpoint);
        } catch (error) {
            log('ERROR ON STATUS TEST - ' + error.message);
            
            // I was trying to store the whole error instead of the message
            return {
                status: error
            }
            //i changed to error.code and now it works
            //return {
            //    status: error.code
            //}
        }

        return { status: response.status};
    }

const data = await sendStatusTest(statusTestEndpoint')

await prisma.example.create({ data })

[jkomyno]

Hi @KevNik, thanks for your reproduction. Can you please share which TypeScript version you used?
Also, if you could, can you share how large error.toString().length would be in the snippet above? Thanks.

[KevNik]

Sorry, i'm not using TypeScript.

import axios from 'axios';
try {
    await axios.get('http://192.168.40.215/dummy-endpoint')
} catch (e) {
    // this line is 1753 char long
    console.log(JSON.stringify(e).length)

}

[millsp]

@KevNik since your issue is at runtime and not about types, could you please create a separate issue?

[millsp]

Since we haven't received a reproduction and given the age of this issue (reported for 2.19.0), we are closing it. But of course, happy to re-open it if you can provide us with a reproduction or more information to dig into. Thanks for your understanding!