#strictUndefinedChecks undesired behavior

1 messages · Page 1 of 1 (latest)

past zodiac
#

hey,

I am really happy to see the new preview feature strictUndefinedChecks . However, I did run into some confusion testing.

When using it I notice that errors are thrown during create and update operations, specifically when an undefined value is used in the data object of the query.

Using the following schema as an example:

model TrpcQueries {
  id            Int      @id @default(autoincrement())
  correlationId String
  path          String
  duration      Int
  userId        String?
  ipv4          String?
  createdAt     DateTime @default(now())

  User User? @relation(fields: [userId], references: [id])

  @@index([userId])
  @@index([correlationId])
}

In this schema, ipv4 is optional. However, when I use a header that might be undefined, like so:

await prisma.trpcQueries.create({
  data: {
    correlationId: "id...",
    path: "path",
    duration: 123,
    ipv4: ctx.headers?.get('x-forwarded-for'),
  },
});

I was wondering why an undefined value isn’t allowed here. If undefined values are indeed disallowed, wouldn’t it be helpful if the types only accepted a string or null instead? This way, any potential issues could be caught during development instead of at runtime.

rich windBOT
#

You selected the carefully hand-crafted route. A dev artisan will respond soon. Meanwhile, the #ask-ai channel awaits if you're curious!

near crag
#

Can you try using Prisma.Skip?

await prisma.trpcQueries.create({
  data: {
    correlationId: "id...",
    path: "path",
    duration: 123,
    ipv4: ctx.headers?.get('x-forwarded-for') ?? Prisma.skip,
  },
});

The Prisma.skip symbol can be used to explicitly omit the field from the query if it is undefined.

past zodiac
#

this doesn't really address the full problem of the findFirst. Before this new preview feature came into effect we'd have to remember to check if the field we were querying by was undefined or not, we seemlying still need to remember to do this for every potentially undefined field?

Just going back to the original post,

If undefined values are indeed disallowed, wouldn’t it be helpful if the types only accepted a string or null instead? This way, any potential issues could be caught during development instead of at runtime.
I think this would be a major improvement, and it wouldn't require us to remember to use Prisma.skip everytime we use an undefined field?

#

I think the current implementation of this will just introduce more bugs because we get no intellisense from typescript saying that this could potentially cause an error due to prisma not allowing undefined values

past zodiac
#

I ran into a bug today because of this, typescript doesnt detect the issue, at all. Opening up alot of doors to run time errors.

dashboard:dev: → 283     await __TURBOPACK__imported__module__$5b$project$5d2f$apps$2f$dashboard$2f$src$2f$server$2f$db$2e$ts__$5b$app$2d$route$5d$__$28$ecmascript$29$__["db"].account.update({
dashboard:dev:             where: {
dashboard:dev:               id: "123"
dashboard:dev:             },
dashboard:dev:             data: {
dashboard:dev:               access_token: "123",
dashboard:dev:               refresh_token: "123",
dashboard:dev:               user: {
dashboard:dev:                 update: {
dashboard:dev:                   name: "123",
dashboard:dev:                   image: undefined,
dashboard:dev:                          ~~~~~~~~~
dashboard:dev:                   email: "[email protected]"
dashboard:dev:                 }
dashboard:dev:               },
dashboard:dev:               updatedAt: new Date("2025-03-03T16:49:24.928Z")
dashboard:dev:             }
dashboard:dev:           })
dashboard:dev:
dashboard:dev: Invalid value for argument `update`: explicitly `undefined` values are not allowed.

User model showing image is completely optional, so in my opional undefined should be an allowed value, or at the very least the types should tell us undefined isn't allowed, so we would have to use null instead.

model User {
  id               String             @id @default(cuid())
  name             String?
  email            String?            @unique
  emailVerified    DateTime?
  image            String?
image.png
past zodiac
#

@near crag do you have any input on this? ^

#

if not, is there anywhere i should be providing feedback for this feature before it exits preview

near crag