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

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…

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.

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 })

@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.

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.

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.

Hi @Bjoernstjerne could you contact us at schemas@prisma.io so we can handle this privately? NDA is no problem of course.

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.

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

@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.

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

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 🙏 ?

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