findMany with a select argument errors out with models with self-relations (sometimes)

[sdnts]

Bug description

The "sometimes" is dependent on the order of scalars with respect to the self relation in the select argument. Details follow.
@kunovsky originally discovered this in their schema, I've managed to narrow down the problem.

How to reproduce

1. In a new folder, place this schema:

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

datasource db {
  provider = "postgresql"
  url      = "postgresql://siddhant@localhost:5432/throwaway"
}

model User {
  id                  String   @default(cuid()) @id
  createdAt           DateTime @default(now())
  updatedAt           DateTime @updatedAt
  updatedBy           String?
  updatedByUser       User?    @relation("UserUpdatedByToUser", fields: [updatedBy], references: [id])
  active              Boolean  @default(true)
  email               String   @unique
  name                String?
  registryAccessToken String   @unique
  User                User[]   @relation("UserUpdatedByToUser")
}

(Note that the User field was automatically added by the VSCode extension)

2. Run prisma migrate save --experimental && prisma migrate up --experimental
3. In an index.ts file in the folder, paste this:

Expand

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

const main = async () => {
  console.log(
    await prisma.user.create({
      data: {
        email: "test@example.com",
        registryAccessToken: "",
      },
    })
  );

  console.log(
    await prisma.user.findMany({
      first: 100,
      select: {
        updatedBy: true,
        updatedByUser: true,
        active: true,
      },
    })
};

main()
  .catch(async (e) => console.log(e))
  .finally(async () => await prisma.disconnect());

4. Run the script using ts-node index.ts.
5. You should see this error:

PrismaClientUnknownRequestError:
Invalid `prisma.user.findMany()` invocation in
/Users/siddhant/Code/Tests/tmp/index.ts:16:23

  12   })
  13 );
  14 console.log(
→ 15   await prisma.user.findMany(Attempted to serialize scalar 'null' with incompatible type 'String'
    at PrismaClientFetcher.message (/Users/siddhant/Code/Tests/tmp/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:649:46)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

Okay I needed you to copy & paste the script above because the issue seems to only happen when a scalar field is after the self-relation in the select argument. Yeah...

A few other things of value:

1. If you remove the select argument entirely, then the script does not crash
2. If you remove the select.updatedByUser argument, then the script does not crash
3. If you remove the select.updatedBy argument, then the script does not crash
4. If you move the select.registryAccessToken argument above the select.updatedByUser argument, then the script does not crash :P
5. If you replace select.registryAccessToken with select.name or select.active, then the script DOES crash, albeit with a different error message (it looks similar though).
6. This only happens with self-relations. I tried doing the same thing with two models and they behave as expected.

Here are the GraphQL queries generated:

1. For select: { updatedBy: true, updatedByUser: true, active: true } (Crashes)

query {
  findManyUser(first: 100) {
    updatedBy
    updatedByUser {
      id
      createdAt
      updatedAt
      updatedBy
      active
      email
      name
      registryAccessToken
    }
    active
  }
}

2. For select: { updatedBy: true, updatedByUser: true, active: true } (Scalar before relation, does not crash)

query {
  findManyUser(first: 100) {
    updatedBy
    active
    updatedByUser {
      id
      createdAt
      updatedAt
      updatedBy
      active
      email
      name
      registryAccessToken
    }
  }
}

3. For select: { updatedBy: true, active: true } (Removed relation, does not crash)

query {
  findManyUser(first: 100) {
    updatedBy
    active
  }
}

Expected behavior

1. The script should not crash
2. The order of select arguments should not determine if the script crashes or not

Environment & setup

• OS: macOS
• Database: Postgres
• Prisma version:

@prisma/cli          : 2.0.0-beta.5
Current platform     : darwin
Query Engine         : query-engine 0c2ec197653b278b2978845ef958db88824cd82e
Migration Engine     : migration-engine-cli 0c2ec197653b278b2978845ef958db88824cd82e
Introspection Engine : introspection-core 0c2ec197653b278b2978845ef958db88824cd82e
Format Binary        : prisma-fmt 0c2ec197653b278b2978845ef958db88824cd82e

• Node.js version: v12.16.3

[pantharshit00]

Thanks for the detailed write up Sid! I can confirm this.

[janpio]

Please add the SQL to the issue, so usage of Migrate is not required to reproduce this.

[pantharshit00]

CREATE TABLE "public"."User" (
"active" boolean  NOT NULL DEFAULT true,"createdAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,"email" text  NOT NULL ,"id" text  NOT NULL ,"name" text   ,"registryAccessToken" text  NOT NULL ,"updatedAt" timestamp(3)  NOT NULL ,"updatedBy" text   ,
    PRIMARY KEY ("id"))

CREATE UNIQUE INDEX "User.email" ON "public"."User"("email")

CREATE UNIQUE INDEX "User.registryAccessToken" ON "public"."User"("registryAccessToken")

ALTER TABLE "public"."User" ADD FOREIGN KEY ("updatedBy")REFERENCES "public"."User"("id") ON DELETE SET NULL  ON UPDATE CASCADE

[dpetrick]

Fixed with 2.0.0-alpha.1205 onwards.