Expected parent IDs to be set when ordering by parent ID.
See original GitHub issueHi Prisma Team! My Prisma Client just crashed. This is the report:
Versions
Name | Version |
---|---|
Node | v16.16.0 |
OS | debian-openssl-1.1.x |
Prisma Client | 4.3.1 |
Query Engine | c875e43600dfe042452e0b868f7a48b817b9640b |
Database | mysql |
The logs in this case were a useless red herring. There were some of our queryRaw included, but not the problem which was “Invalid prisma.letting.findMany()
invocation:Expected parent IDs to be set when ordering by parent ID. This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.”
I can work on a minimal replication, but this is what we have so far.
Client Snippet
const lettings = await this.context.prisma.agency(agencyid).letting.findMany({
include: {
lettingSchedules: {
where: { iswithdrawn: false },
},
},
orderBy: [
{ lettingid: 'asc' },
],
})
Client Snippet 2 minimal
await prisma.letting.create({
data: {
lettingid: 'UPPERCASE',
}
})
await prisma.lettingSchedule.create({
data: {
lettingid: 'uppercase',
contid: 'some-contid',
}
})
const lettings = await prisma.letting.findMany({
include: { lettingSchedules: true },
})
Schema
model Letting {
lettingid String @id @db.VarChar(45)
lettingdate DateTime? @db.Timestamp(0)
lettingSchedules LettingSchedule[]
@@map("letting")
}
model LettingSchedule {
lettingid String @db.VarChar(45)
contid String @db.VarChar(45)
callorder String? @db.VarChar(45)
iswithdrawn Boolean?
letting Letting @relation(fields: [lettingid], references: [lettingid])
@@id([lettingid, contid])
@@map("lettingschedule")
}
I’ve cut out some extra where clauses and edited the schema for brevity.
Prisma failed to recognize the link between the tables when lettingid was “29apr11” in letting
and “29APR11” in lettingschedule
.
I had to log in to the production database and change production data to get the cases to match to stop the error.
Issue Analytics
- State:
- Created a year ago
- Comments:6
Top GitHub Comments
Yep! I’ve taken a look and have confirmed your teammate’s reproduction @sdkuck
Yes, this still happens with 4.5.0 We are using MySQL 5.7 ~You didn’t include the prisma.findMany query you used, but in trying to replicate this locally we found that the problem goes away if you have a
where: {...}
clause. Just do the findMany with an include and nothing else.~ Sorry, just saw the repo for the reproduction. I’ll take a look at that and see if we can make it break. Thank you!