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

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: '[e-mail]',
  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: '[e-mail]',
  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

[pantharshit00]

I can confirm this bug. Thanks for the report.

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