Prisma Client mixes up DateTimes and IDs when they are selected in queries

[sdnts]

Bug description

Originally found by @rmatei in prisma/studio#416

How to reproduce

Use this schema:

model Area {
  id        String   @default(cuid()) @id
  name      String
  blocks    Block[]
  score     Float?
  createdAt DateTime @default(now())
  updatedAt DateTime @default(now()) @updatedAt
}

model Block {
  id        String   @default(cuid()) @id
  area      Area     @relation(fields: [areaId], references: [id])
  areaId    String
  createdAt DateTime @default(now())
  updatedAt DateTime @default(now()) @updatedAt
}

And use this script:

import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

const main = async () => {
  const area = await prisma.area.create({
    data: {
      name: 'something',
      score: null,
    },
    select: {
      id: true,
      name: true,
      blocks: true,
      score: true,
      createdAt: true,
      updatedAt: true,
    },
  })
  await prisma.block.create({
    data: {
      area: {
        connect: {
          id: area.id,
        },
      },
    },
    select: {
      id: true,
      area: true,
      areaId: true,
      createdAt: true,
      updatedAt: true,
    },
  })
}

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

You should see this error:

PrismaClientUnknownRequestError:
Invalid `prisma.block.create()` invocation in
/Users/siddhant/Code/Tests/experiments/index.ts:22:22

  18     createdAt: true,
  19     updatedAt: true,
  20   },
  21 })
→ 22 await prisma.block.create(PANIC: called `Result::unwrap()` on an `Err` value: ErrorMessage { msg: "Could not parse stored DateTime string: ckac9lbau0000eg0xrvs7y535 (input contains invalid characters)" }

   0: backtrace::backtrace::trace
   1: backtrace::capture::Backtrace::new_unresolved
   2: failure::backtrace::internal::InternalBacktrace::new
   3: failure::backtrace::Backtrace::new
   4: sql_query_connector::row::row_value_to_prisma_value
   5: <quaint::connector::result_set::result_row::ResultRow as sql_query_connector::row::ToSqlRow>::to_sql_row
   6: <std::future::GenFuture<T> as core::future::future::Future>::poll
   7: <std::future::GenFuture<T> as core::future::future::Future>::poll
   8: std::future::poll_with_tls_context
   9: <std::future::GenFuture<T> as core::future::future::Future>::poll
  10: <std::future::GenFuture<T> as core::future::future::Future>::poll
  11: <std::future::GenFuture<T> as core::future::future::Future>::poll
  12: <std::future::GenFuture<T> as core::future::future::Future>::poll
  13: <std::future::GenFuture<T> as core::future::future::Future>::poll
  14: <std::future::GenFuture<T> as core::future::future::Future>::poll
  15: <std::future::GenFuture<T> as core::future::future::Future>::poll
  16: <std::future::GenFuture<T> as core::future::future::Future>::poll
  17: <std::future::GenFuture<T> as core::future::future::Future>::poll
  18: <std::future::GenFuture<T> as core::future::future::Future>::poll
  19: std::future::poll_with_tls_context
  20: <std::future::GenFuture<T> as core::future::future::Future>::poll
  21: <std::future::GenFuture<T> as core::future::future::Future>::poll
  22: std::panicking::try::do_call
  23: __rust_maybe_catch_panic
  24: <std::future::GenFuture<T> as core::future::future::Future>::poll
  25: <std::future::GenFuture<T> as core::future::future::Future>::poll
  26: <std::future::GenFuture<T> as core::future::future::Future>::poll
  27: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_catch
  28: <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll
  29: <hyper::server::conn::spawn_all::NewSvcTask<I,N,S,E,W> as core::future::future::Future>::poll
  30: tokio::task::core::Core<T>::poll
  31: std::panicking::try::do_call
  32: __rust_maybe_catch_panic
  33: tokio::task::harness::Harness<T,S>::poll
  34: tokio::runtime::thread_pool::worker::GenerationGuard::run_task
  35: tokio::runtime::thread_pool::worker::GenerationGuard::run
  36: std::thread::local::LocalKey<T>::with
  37: tokio::runtime::thread_pool::worker::Worker::run
  38: tokio::task::core::Core<T>::poll
  39: std::panicking::try::do_call
  40: __rust_maybe_catch_panic
  41: tokio::task::harness::Harness<T,S>::poll
  42: tokio::runtime::blocking::pool::Inner::run
  43: tokio::runtime::context::enter
  44: std::sys_common::backtrace::__rust_begin_short_backtrace
  45: std::panicking::try::do_call
  46: __rust_maybe_catch_panic
  47: core::ops::function::FnOnce::call_once{{vtable.shim}}
  48: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  49: std::sys::unix::thread::Thread::new::thread_start
  50: _ZL12preoptimized

    at PrismaClientFetcher.message (/Users/siddhant/Code/Tests/experiments/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:649:46)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
Error in Prisma Client:
PANIC: called `Result::unwrap()` on an `Err` value: ErrorMessage { msg: "Could not parse stored DateTime string: ckac9lbau0000eg0xrvs7y535 (input contains invalid characters)" }

   0: backtrace::backtrace::trace
   1: backtrace::capture::Backtrace::new_unresolved
   2: failure::backtrace::internal::InternalBacktrace::new
   3: failure::backtrace::Backtrace::new
   4: sql_query_connector::row::row_value_to_prisma_value
   5: <quaint::connector::result_set::result_row::ResultRow as sql_query_connector::row::ToSqlRow>::to_sql_row
   6: <std::future::GenFuture<T> as core::future::future::Future>::poll
   7: <std::future::GenFuture<T> as core::future::future::Future>::poll
   8: std::future::poll_with_tls_context
   9: <std::future::GenFuture<T> as core::future::future::Future>::poll
  10: <std::future::GenFuture<T> as core::future::future::Future>::poll
  11: <std::future::GenFuture<T> as core::future::future::Future>::poll
  12: <std::future::GenFuture<T> as core::future::future::Future>::poll
  13: <std::future::GenFuture<T> as core::future::future::Future>::poll
  14: <std::future::GenFuture<T> as core::future::future::Future>::poll
  15: <std::future::GenFuture<T> as core::future::future::Future>::poll
  16: <std::future::GenFuture<T> as core::future::future::Future>::poll
  17: <std::future::GenFuture<T> as core::future::future::Future>::poll
  18: <std::future::GenFuture<T> as core::future::future::Future>::poll
  19: std::future::poll_with_tls_context
  20: <std::future::GenFuture<T> as core::future::future::Future>::poll
  21: <std::future::GenFuture<T> as core::future::future::Future>::poll
  22: std::panicking::try::do_call
  23: __rust_maybe_catch_panic
  24: <std::future::GenFuture<T> as core::future::future::Future>::poll
  25: <std::future::GenFuture<T> as core::future::future::Future>::poll
  26: <std::future::GenFuture<T> as core::future::future::Future>::poll
  27: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_catch
  28: <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll
  29: <hyper::server::conn::spawn_all::NewSvcTask<I,N,S,E,W> as core::future::future::Future>::poll
  30: tokio::task::core::Core<T>::poll
  31: std::panicking::try::do_call
  32: __rust_maybe_catch_panic
  33: tokio::task::harness::Harness<T,S>::poll
  34: tokio::runtime::thread_pool::worker::GenerationGuard::run_task
  35: tokio::runtime::thread_pool::worker::GenerationGuard::run
  36: std::thread::local::LocalKey<T>::with
  37: tokio::runtime::thread_pool::worker::Worker::run
  38: tokio::task::core::Core<T>::poll
  39: std::panicking::try::do_call
  40: __rust_maybe_catch_panic
  41: tokio::task::harness::Harness<T,S>::poll
  42: tokio::runtime::blocking::pool::Inner::run
  43: tokio::runtime::context::enter
  44: std::sys_common::backtrace::__rust_begin_short_backtrace
  45: std::panicking::try::do_call
  46: __rust_maybe_catch_panic
  47: core::ops::function::FnOnce::call_once{{vtable.shim}}
  48: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  49: std::sys::unix::thread::Thread::new::thread_start
  50: _ZL12preoptimized
 in
query-engine/connectors/sql-query-connector/src/row.rs:119:26

This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.
Please create an issue in https://github.com/prisma/prisma-client-js describing the last Prisma Client query you called.

This seems similar to #2442, in that the problem seems to be with the select argument of the create query. If I don't select anything, then the script does not crash.
This time though, QE seems to be mixing up DateTimes and IDs.

If you think this is the same issue, please feel free to close this and add this as a comment to #2442

Expected behavior

1. The script should not crash
2. The arguments I pass in to select (or if I don't use it at all) should not dictate 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 another great write up 👍

I can reproduce this.

Version information:

Environment variables loaded from ./prisma/.env
@prisma/cli          : 2.0.0-alpha.1219
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine 86cf27779951480f87f6bbdb15a3722c5756a8e4 (at /home/harshit/code/reproductions/issue-2501/node_modules/@prisma/cli/query-engine-debian-openssl-1.1.x)
Migration Engine     : migration-engine-cli 86cf27779951480f87f6bbdb15a3722c5756a8e4 (at /home/harshit/code/reproductions/issue-2501/node_modules/@prisma/cli/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core 86cf27779951480f87f6bbdb15a3722c5756a8e4 (at /home/harshit/code/reproductions/issue-2501/node_modules/@prisma/cli/introspection-engine-debian-openssl-1.1.x)
Format Binary        : prisma-fmt 86cf27779951480f87f6bbdb15a3722c5756a8e4 (at /home/harshit/code/reproductions/issue-2501/node_modules/@prisma/cli/prisma-fmt-debian-openssl-1.1.x)

SQL required for database creation:

CREATE TABLE "public"."Area" (
"createdAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,"id" text  NOT NULL ,"name" text  NOT NULL ,"score" Decimal(65,30)   ,"updatedAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY ("id"))

CREATE TABLE "public"."Block" (
"areaId" text  NOT NULL ,"createdAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,"id" text  NOT NULL ,"updatedAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY ("id"))

ALTER TABLE "public"."Block" ADD FOREIGN KEY ("areaId")REFERENCES "public"."Area"("id") ON DELETE CASCADE  ON UPDATE CASCADE

[rmatei]

Cool! Impressed by the quick response guys, and excited for a resolution 😊

[lutz404]

Yes, same bug.

PANIC: called Result::unwrap() on an Err value: ErrorMessage { msg: "Could not parse stored DateTime string: 2020-05-19 02:07:54 (input contains invalid characters)" }

My schema is:

model User {
id Int @id @default(autoincrement())
email String @unique
name String?
age Int @default(0)
posts Post[]
createdAt DateTime @default(now())
updatedAt DateTime? @updatedAt
}

The command is:

const user = await prisma.user.update( { where: {id: Number(req.params.id) }, data: req.body } );

[janpio]

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

[pantharshit00]

CREATE TABLE "public"."Area" (
"createdAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,"id" text  NOT NULL ,"name" text  NOT NULL ,"score" Decimal(65,30)   ,"updatedAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY ("id"))

CREATE TABLE "public"."Block" (
"areaId" text  NOT NULL ,"createdAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,"id" text  NOT NULL ,"updatedAt" timestamp(3)  NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY ("id"))

ALTER TABLE "public"."Block" ADD FOREIGN KEY ("areaId")REFERENCES "public"."Area"("id") ON DELETE CASCADE  ON UPDATE CASCADE

[dpetrick]

Fixed with 2.0.0-alpha.1205 onwards.

[divyenduz]

I am still able to reproduce this with the latest alpha. Assigning @pantharshit00 to reconfirm.

[dpetrick]

Can't confirm that the issue is still appearing on latest alpha. All raw GraphQL queries against the engine produce the expected result. Are you sure you were on or above the listed alpha version?

[sdnts]

I can confirm that it works too, using the schema & script I posted in the OP.

[pantharshit00]

I also can't reproduce this with 2.0.0-alpha.1257. @divyenduz can you please make sure you ran npx prisma generate if you upgraded the old package, just to be sure.

[divyenduz]

Sounds good, thanks for the confirmation everyone.