Introspection is printing out relation field as nullable when one of composite foreign key field is nullable

Hi Prisma Team! My Prisma Client just crashed. This is the report:

Versions

Name	Version
Node	v14.8.0
OS	debian-openssl-1.1.x
Prisma	2.5.1

Logs

  prisma-client {
  prisma-client   engineConfig: {
  prisma-client     cwd: '/home/jp/.../prisma',
  prisma-client     enableDebugLogs: false,
  prisma-client     enableEngineDebugMode: undefined,
  prisma-client     datamodelPath: '/home/jp/.cache/prisma/studio/.../schema.prisma',
  prisma-client     prismaPath: undefined,
  prisma-client     engineEndpoint: undefined,
  prisma-client     generator: {
  prisma-client       binaryTargets: [],
  prisma-client       previewFeatures: [],
  prisma-client       config: [Object],
  prisma-client       name: 'photon',
  prisma-client       provider: 'prisma-client-js',
  prisma-client       output: '/home/jp/.cache/prisma/studio/...',
  prisma-client       isCustomOutput: true
  prisma-client     },
  prisma-client     showColors: false,
  prisma-client     logLevel: undefined,
  prisma-client     logQueries: undefined,
  prisma-client     flags: [],
  prisma-client     clientVersion: '2.5.1',
  prisma-client     enableExperimental: [],
  prisma-client     useUds: undefined
  prisma-client   }
  prisma-client }  
  plusX Execution permissions of /home/jp/.cache/prisma/studio/.../query-engine-debian-openssl-1.1.x are fine  
  prisma-client Client Version 2.5.1  
  prisma-client Engine Version c88925ce44a9b89b4351aec85ba6a28979d2658e  
  plusX Execution permissions of /home/jp/.cache/prisma/studio/.../query-engine-debian-openssl-1.1.x are fine  

Generating Prisma Client ... done
Studio started at http://localhost:5555
Error in request:  PrismaClientRustPanicError: PANIC: Application logic invariant error: received null value for field AlarmUser which may not be null

query: 'prisma.alarmOccurrence.findMany({\n' +
    '  take: 100,\n' +
    '  skip: 0,\n' +
    '  select: {\n' +
    '    id: true,\n' +
    '    time: true,\n' +
    '    alarmId: true,\n' +
    '    sensorId: true,\n' +
    '    acknowledgedAt: true,\n' +
    '    acknowledgedByUserId: true,\n' +
    '    normalizedAt: true,\n' +
    '    AlarmUser: true,\n' +
    '    AlarmSensor: true,\n' +
    '  }\n' +
    '})'

Context

Here are the relevant schema parts:

CREATE TABLE "Alarm" (
  "id" SERIAL PRIMARY KEY NOT NULL
);

CREATE TABLE "AlarmSensor" (
  "alarmId" INTEGER NOT NULL REFERENCES "Alarm"("id"),
  "sensorId" INTEGER NOT NULL REFERENCES "Sensor"("id"),
  PRIMARY KEY ("alarmId", "sensorId")
);

CREATE TABLE "AlarmUser" (
  "alarmId" INTEGER NOT NULL REFERENCES "Alarm"("id"),
  "userId" INTEGER NOT NULL REFERENCES "User"("id"),
  PRIMARY KEY ("alarmId", "userId")
);

CREATE TABLE "AlarmOccurrence" (
  "id" SERIAL PRIMARY KEY NOT NULL,
  "time" TIMESTAMP NOT NULL DEFAULT now(),
  "alarmId" INTEGER NOT NULL,
  "sensorId" INTEGER NOT NULL,
  "acknowledgedAt" TIMESTAMP,
  "acknowledgedByUserId" INTEGER,

  -- Both FKs share the same alarmId,
  -- but I want acknowledgedByUserId to be initially null:

  FOREIGN KEY ("alarmId", "sensorId") REFERENCES "AlarmSensor"("alarmId", "sensorId"),

  -- MATCH SIMPLE: If any of the columns on which a foreign key is defined is NULL,
  -- the foreign key is not enforced.
  FOREIGN KEY ("alarmId", "acknowledgedByUserId")
    REFERENCES "AlarmUser"("alarmId", "userId") MATCH SIMPLE
);

Look, I’m not a database design expert. So if you think I could improve this somehow, I would love to learn how to do it!

Using raw SQL, I can create a new AlarmOccurrence with acknowledgedByUserId initially set to null. But if I open Prisma Studio to view the table row, it throws the error.

Using Prisma to create the AlarmOccurrence, both FKs are being marked as required, which is not the desired behavior.

Edit: If I set alarmId as NULL, acknowledgedByUserId is not marked as required anymore by Prisma. But I still think the default FK behavior should be followed here…

[pantharshit00]

This bug is confirmed anyways so you might as well wait for the fix.

[do4gr]

Hey, thanks for reporting this in such detail @joaopaulobdac . There is definitely need for action here, we’re discussing possible approaches at the moment. I will update again once we agreed on an approach.