When rejectOnNotFound is used, chaining deeper into a related table still throws if it doesn't find anything

[capaj]

Bug description

rejectOnNotFound should not cause chained queries to fail if they don't find an entity.
It is best understood by looking at the reproduction example:

How to reproduce

Have a code like this:

import { PrismaClient, Prisma } from '@prisma/client'

const prismaClient = new PrismaClient()

; (async () => {
        const existingUser = await prismaClient.user.findUnique({
            where: {
                id: 1
            },
        })
        console.log('~ existingUser', existingUser)
        const user = prismaClient.user.findUnique({
            where: {
                id: 1
            },
            rejectOnNotFound: true
        })
        console.log( await user.profilePicture())
})()

Running this code using ts-node pr.ts prints out:

~ existingUser {
  id: 1,
  createdAt: 2021-12-10T11:24:30.096Z,
  email: 'john@example.com',
  name: null,
  role: 'USER',
  profilePictureId: null
}
[NotFoundError: No User found] { clientVersion: '3.6.0' }

Expected behavior

Expected output for me is this:

~ existingUser {
  id: 1,
  createdAt: 2021-12-10T11:24:30.096Z,
  email: 'john@example.com',
  name: null,
  role: 'USER',
  profilePictureId: null
}
null

Without throwing any errors.

Prisma information

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = "file:./bugRepro.db"
}

model User {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  email     String   @unique
  name      String?

  role             String @default("USER")
  profilePictureId Int?
  profilePicture   Image? @relation(fields: [profilePictureId], references: [id])
}

model Image {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  isHeader  Boolean  @default(false)
  url       String
  User      User[]
}

Environment & setup

• OS: ubuntu
• Database: any
• Node.js version: 17

Prisma Version

prisma                  : 3.6.0
@prisma/client          : 3.6.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : dc520b92b1ebb2d28dc3161f9f82e875bd35d727
Studio                  : 0.440.0

[capaj]

Someone might say that this behaviour is correct-that prisma is intentionally using rejectOnNotFound: true in chained queries. If that's the case there is still a bug-expected error in that case would be:

[NotFoundError: No Image found] { clientVersion: '3.6.0' }

If this is how it is intended, then it is a bad default IMHO, because in most cases you want the throw to only apply to a single level when chaining queries. Especially if you have a helper method which gets reused in multiple places.

[MichalLytek]

I also suffer from the same issue. I find it a bug because it throws No XYZ found error where XYZ is the name of the base entity which exists in db, only the relation is missing.

[capaj]

There is definitely a bug, there's just no indication anywhere whether rejectOnNotFound: true should propagate down when chaining queries or not. So there are only 2 options:

1. bug is just in the message of the error, otherwise the query behaves as designed/expected
2. bug is also in the behaviour, so it should not propagate down into chained queries

I hope it's 2. because I really think this is not a good default as it disallows a bunch of usecases.

[pantharshit00]

I can confirm this bug. Thanks for the report.

[SevInf]

Can reproduce it with *OrThrow varaints of findFirst and findUnique: #15887