prisma: 4.16: (MongoDB) Generated types for list composites are incorrect

Still having this issue with 4.16.1 Generated types have objects, scalars and composites on them breaking our codebase relying on them

I tried with the dev version that had the fix and types are still not being generated with the right payload

@prisma/client@4.16.1-dev.7

This was happening in our CI on 4.15.0, we upgraded to 4.16.1 hoping the issue was fixed there Turns out, this was happening because the CI didnt have the development lock file and was pulling a newer engine version (14.6.1)

Environment variables loaded from .env
prisma                  : 4.16.1
@prisma/client          : 4.16.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine b20ead4d3ab9e78ac112966e242ded703f4a052c (at ../../../../../.nvm/versions/node/v18.16.1/lib/node_modules/prisma/node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli b20ead4d3ab9e78ac112966e242ded703f4a052c (at ../../../../../.nvm/versions/node/v18.16.1/lib/node_modules/prisma/node_modules/@prisma/engines/migration-engine-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.16.0-66.b20ead4d3ab9e78ac112966e242ded703f4a052c
Default Engines Hash    : b20ead4d3ab9e78ac112966e242ded703f4a052c
Studio                  : 0.484.0

4.16.2-dev.1 seems to be working now, our schema is kind of beefy, 450 lines so I assume I’ts working

@SevInf I’m not getting anymore type errors using 4.16.2-dev.1 on my repo.

@pheuter thank you, I was able to reproduce the issue with your information. We are working on a fix at the moment. Fix will make it into patch release we are publishing soon.

@dovidk could you share the reproduction? The code you are executing and the models it uses. The one @pheuter shared before is fixed in 4.16.1 and we have nothing else that would allow us to reproduce the issue.

My case is similar to @pheuter. I have an optional type on a model that is breaking.

@SevInf Looks like 4.16.1 was just a partial fix that only examined my one cherry picked example above. On 4.16.1, I continue to see similar errors involving Payload types containing objects and scalars.

The one @pheuter shared before is fixed in 4.16.1 and we have nothing else that would allow us to reproduce the issue.

It’s somewhat worrying that a big, popular library like Prisma does not have an internal test suite with at least one schema.prisma file containing models, types, and fields that are commonly found in a MongoDB configuration. I don’t understand how you’re completely at the mercy of users reporting breaking bugs on released versions to only then uncover these issues…

Anyway, here is another example similar to above, this time the nested type is optional instead of an array:

model SomeModel {
  id           String      @id @default(auto()) @map("_id") @db.ObjectId
  optionalType SomeType?
}

type SomeType {
  // This gets improperly generated to a `SomeTypePayload` containing `objects` and `scalars`
}

Again, I will reiterate my concern from above that this is a very standard and basic use case that should have easily failed some tests on your side, and the fact that you solely went off my one example above that used a nested array and didn’t look at any other variations is not ideal.

@Tirke Thanks for the bug issue!

@pheuter @goktug7913 @MahmoudAlawdh

It’s now published in our patch-dev version 4.16.1-dev.7.

Let us know if this version fixes the issues, we’re curious to get any feedback 🙌🏼

Note: do not use in production, wait for the official 4.16.1 patch for that, coming very soon!

thanks a lot, i’ll update our dev branch and see how it goes!

I’m seeing the same issues that’s causing hundreds of type errors in our codebase now. Here is one example:

schema.prisma:

model Recipient {
    id String @id @default(auto()) @map("_id") @db.ObjectId
    
    firstName     String
    lastName      String
    preferredName String?

    contacts  EmergencyContact[]
}

type EmergencyContact {
    id                  String   @db.ObjectId
    firstName           String
    lastName            String
    phone               String
    email               String?
    isPrimary           Boolean?
    relationship        String?
    company             String?
    billingAddressLine1 String?
    billingAddressLine2 String?
    billingCity         String?
    billingState        State?
    billingZip          String?
}

Server ts function:

const recipient = await prisma.recipient.findFirstOrThrow({
	where: {
		id: recipientId
	}
});

recipient.contacts // Assigned type of `EmergencyContactPayload[]`

Generated .prisma/client/index.d.ts:

export type EmergencyContactPayload = {
  objects: {}
  scalars: {
    id: string
    firstName: string
    lastName: string
    phone: string
    email: string | null
    isPrimary: boolean | null
    relationship: string | null
    company: string | null
    billingAddressLine1: string | null
    billingAddressLine2: string | null
    billingCity: string | null
    billingState: State | null
    billingZip: string | null
  }
  composites: {}
}

This new EmergencyContactPayload is causing issues since it contains fields like objects and scalars instead of the type of the actual EmergencyContact.

/cc @SevInf

Looks like 4.16.2 fixes the issue, thanks.

4.16.2-dev.1 fixes my issue

latest version did not work for us too, some types are still causing errors. We will stick to 4.15.0 for now as I really dont want to manage versions on 3 servers 🫠

@dovidk could you share the reproduction? The code you are executing and the models it uses. The one @pheuter shared before is fixed in 4.16.1 and we have nothing else that would allow us to reproduce the issue.