Incorrect Include typings when having models called X and XUpdate

[ianmartorell]

Bug description

When having two models called X and XUpdate, the generated types for include parameters of XUpdate are incorrect.

How to reproduce

Example (only relevant fields included):

model Product {
  id      String          @id @default(uuid())
  updates ProductUpdate[] @relation(name: "ProductUpdates")
}

model ProductUpdate {
  id        String  @id @default(uuid())
  productId String
  product   Product @relation(name: "ProductUpdates", fields: [productId], references: [id])
}

Then, when querying another model that has a relation with ProductUpdate:

prisma.orderItem.findUnique({
  where: {
    id,
  },
  include: {
    productUpdate: {
      include: {
        product: true,
      },
    },
  },
})

I get the following error:

Looking at the generated types, this seems to be because the productUpdate field in OrderItemInclude has type ProductUpdateArgs, which are the arguments for an update operation on a Product model, instead of the args without action of the ProductUpdate model.

Expected behavior

The type of OrderItemInclude.productUpdate should be related to the ProductUpdate model, not the Product model. Consequently there should not be a type error in this situation.

Prisma information

Relevant prisma schema provide above.

Environment & setup

• OS: macOS
• Database: PostgreSQL
• Node.js version: 15.14.0

Prisma Version

Environment variables loaded from .env
@prisma/cli          : 2.13.1
@prisma/client       : 2.13.1
Current platform     : darwin
Query Engine         : query-engine fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt fcbc4bb2d306c86c28014f596b1e8c7980af8bd4 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Studio               : 0.329.0

[pantharshit00]

Hey @ianmartorell

Can you please try this again with the latest version ? 2.13.1 is very old now so this might be already fixed.

If you can still reproduce this, please also share the schema of OrderItem model as it is being used in the reproduction call here.

[ianmartorell]

Hi @pantharshit00, I have updated Prisma to the latest version (2.25.0) and the issue persists.

Since I have both a model called Product and ProductUpdate, there's a conflict in the generated types, and typescript expects the type of the includes of productUpdate to be ProductInclude, instead of ProductUpdateInclude.

Here's the schema of OrderItem, removing a bunch of non-relevant fields:

model OrderItem {
  id                         String          @id @default(uuid())
  quantity                   Int             @default(1)
  createdAt                  DateTime        @default(now())
  updatedAt                  DateTime        @updatedAt
  productUpdateId            String
  productUpdate              ProductUpdate   @relation(fields: [productUpdateId], references: [id])
  orderId                    String
  order                      Order           @relation(fields: [orderId], references: [id])
  orderItemStatusId          String
  orderItemStatus            OrderItemStatus @relation(fields: [orderItemStatusId], references: [id])
}

[ianmartorell]

Here's a repro https://github.com/ianmartorell/prisma-issue-7518

[ianmartorell]

@janpio @pantharshit00 Any idea when this could be looked over? If it's gonna take a while, I'll dedicate some time to rework our current Prisma schema to avoid this issue.

[janpio]

Next step would be for @pantharshit00 to get a confirmed reproduction, then someone from the developers would take a look and hopefully directly be able to reproduce as well, and then find a fix. Hard to say how complex that will be, before it actually happens - sorry.

[ianmartorell]

No problem, thank you for the quick reply :)

[pantharshit00]

Sorry for the late reply here. This got buried in my notifications.

I can confirm the conflict and marking this as candidate.

[SevInf]

This issue is now fixed and the fix will be published as a part of 5.1 release. If you'd like to verify fix earlier, you can use dev snapshot 5.1.0-dev.24. We don't recommend using it in production, but it should be enough to verify the fix.