Certain database rows cause prisma client to crash

Bug description

When running the Prisma.model.findMany command one of my rows in sql causes Prisma to crash and output this error. Im not entirely sure if there’s a malformed value in my database. Im also not 100% sure what this error is trying to tell me or what column is causing this error.

thread 'tokio-runtime-worker' panicked at 'Given exponent overflowing the maximum accepted scale (255).: TryFromIntError(())', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/tiberius-0.9.3/src/tds/numeric.rs:287:47
stack backtrace:
   0:        0x114188924 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h188b7ef1c7993e78
   1:        0x1141a8020 - core::fmt::write::he84a3004e7af3f34
   2:        0x114182bf4 - std::io::Write::write_fmt::h9370b50affaab0be
   3:        0x11418a070 - std::panicking::default_hook::{{closure}}::hc074f8023cce83ca
   4:        0x114189dd8 - std::panicking::default_hook::hef854b51b9b79ff2
   5:        0x11418a508 - std::panicking::rust_panic_with_hook::h1e59e224d558a492
   6:        0x11418a43c - std::panicking::begin_panic_handler::{{closure}}::he1a9d6ab32bfd8c6
   7:        0x114188e00 - std::sys_common::backtrace::__rust_end_short_backtrace::he9b94791b02f48cd
   8:        0x11418a194 - _rust_begin_unwind
   9:        0x11420f964 - core::panicking::panic_fmt::h9fec86f6a9c4146e
  10:        0x11420fa08 - core::result::unwrap_failed::h04f08301b97a771c
  11:        0x113dc9690 - tiberius::tds::numeric::bigdecimal_::<impl tiberius::to_sql::ToSql for core::option::Option<bigdecimal::BigDecimal>>::to_sql::he5f2c3bc35de62b0
  12:        0x113a3e4f4 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h1bb2b6a9432cac5a
  13:        0x113b4b484 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h2c448aba16cbe0dd
  14:        0x113a45154 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h2d24b4e1de521fc1
  15:        0x113a67c5c - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hd131c838039a4de9
  16:        0x113a426a0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h29d081eee69d4353
  17:        0x1135e9cb0 - <tracing_futures::Instrumented<T> as core::future::future::Future>::poll::h6a0e88c60196da0f
  18:        0x1135c61b8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h23c0ec236bd0df8d
  19:        0x1135bfabc - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h18a32ffe68cbd829
  20:        0x1135d38c8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h9e8ceff94408aad4
  21:        0x1132b68f4 - query_core::interpreter::query_interpreters::read::read_related::{{closure}}::h14363e55dbc2eaee
  22:        0x1132a8d10 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h378feeca0e4e39a2
  23:        0x1132ab050 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h8100932631ec4597
  24:        0x1132a3ba4 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h07f4ac0fa08d642e
  25:        0x1132aa3a8 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7db6055ee109787b
  26:        0x1132ab080 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h8100932631ec4597
  27:        0x11326c824 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h355e260569f4cfa6
  28:        0x1132a3568 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h07796cc1a1e899eb
  29:        0x1132a92d0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7106db4746c0e007
  30:        0x1130c38e0 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::hf1dd5c4c78895573
  31:        0x113072cc0 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hb5050e51c5321afd
  32:        0x11306f674 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h997271f988289b2d
  33:        0x11307e024 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hd10e9bfc8e75506a
  34:        0x113064358 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h361ae0ceb45fab66
  35:        0x11306a390 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h73b5b997c96f0f75
  36:        0x11306c71c - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7d8bfc95225ffe44
  37:        0x1130c35e0 - <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll::h9106f7b9f1dc9491
  38:        0x113078594 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hbdf923899c928647
  39:        0x113081c60 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hde71dadbf14e540e
  40:        0x1130670cc - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h5b7ac248ee7f63fd
  41:        0x1131306f0 - tokio::runtime::task::core::CoreStage<T>::poll::hffd92748427be685
  42:        0x11300929c - tokio::runtime::task::harness::poll_future::h0b21672fa4bef1c1
  43:        0x11300d85c - tokio::runtime::task::harness::Harness<T,S>::poll::h21d125b77f2c8822
  44:        0x113dec290 - std::thread::local::LocalKey<T>::with::h9edccece6c2f3963
  45:        0x113e027cc - tokio::runtime::thread_pool::worker::Context::run_task::h3f0afe5218ac3f54
  46:        0x113e01b18 - tokio::runtime::thread_pool::worker::Context::run::h0aab08c900c3bd18
  47:        0x113defbac - tokio::macros::scoped_tls::ScopedKey<T>::set::h28c8de06c0a15374
  48:        0x113e015e0 - tokio::runtime::thread_pool::worker::run::hf7b13b0164905c27
  49:        0x113df8c00 - <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll::hc3991b35707512ae
  50:        0x113df9f08 - tokio::runtime::task::harness::Harness<T,S>::poll::h0e33bd385a4898d3
  51:        0x113de4cf8 - tokio::runtime::blocking::pool::Inner::run::h55cea32f5020a611
  52:        0x113debf54 - std::sys_common::backtrace::__rust_begin_short_backtrace::h756ca1dda46c8a00
  53:        0x113decb68 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h96e9be7d1b666a9d
  54:        0x11418e828 - std::sys::unix::thread::Thread::new::thread_start::h7b2f9b83fb320a20
  55:        0x19ff8026c - __pthread_deallocate

/Users/collinsmallegan/Projects/Materials Resources/Prophet21Connector/node_modules/@prisma/client/runtime/index.js:29917
      throw new PrismaClientRustPanicError(message, this.client._clientVersion);
            ^
Error: 
Invalid `this.prisma.inventory_receipts_hdr.findUnique()` invocation in
/Users/collinsmallegan/Projects/Materials Resources/Prophet21Connector/src/orders/orders.service.ts:10:47

   7 constructor(private prisma: PrismaService) {}
   8 
   9 async readPickTicket(request: readPickTicketRequest) {
→ 10   return this.prisma.inventory_receipts_hdr.findUnique(
Given exponent overflowing the maximum accepted scale (255).: TryFromIntError(())

This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.

How to reproduce

Expected behavior

Prism a shouldn’t crash when running a query.

Prisma information

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

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

datasource db {
  provider = "sqlserver"
  url      = env("DATABASE_URL")
}


model invoice_hdr {
  invoice_no   String  @id(map: "pk_invoice_hdr", clustered: false) @db.VarChar(10)
  ship2_state  String
  total_amount Decimal @default(0, map: "df_invoice_hdr_total_amount") @db.Decimal(19, 4)
}

model oe_pick_ticket {
  pick_ticket_no Decimal @id(map: "pk_oe_pick_ticket") @db.Decimal(19, 0)
}

model oe_hdr {
  order_no              String  @id(map: "pk_oe_hdr") @db.VarChar(8)
  delivery_instructions String?  @db.VarChar(255)
  oe_hdr_uid            Int     @unique(map: "ak_oe_hdr_uid")
  ship2_add1            String? @db.VarChar(50)
  ship2_add2            String? @db.VarChar(50)
  ship2_country         String? @db.VarChar(50)
  ship2_city            String? @db.VarChar(50)
  ship2_state           String? @db.VarChar(50)
  ship2_zip             String? @db.VarChar(10)
}

model inventory_receipts_hdr {
  receipt_number Decimal @id(map: "pk_inventory_receipts_hdr") @db.Decimal(19, 0)
  inventory_receipts_line inventory_receipts_line[]
}

model inventory_receipts_line {
  receipt_number Decimal @db.Decimal(19, 0)
  line_number    Int

  inv_mast_uid    Int
  qty_received    Decimal @db.Decimal(19, 9)
  unit_of_measure String  @db.VarChar(8)

  //inv_mast                       inv_mast                         @relation(fields: [inv_mast_uid], references: [inv_mast_uid], onUpdate: NoAction, map: "FK50ofotx2q7fdwomayg9kvuss2")
  inventory_receipts_hdr inventory_receipts_hdr @relation(fields: [receipt_number], references: [receipt_number], onUpdate: NoAction)

  @@id([receipt_number, line_number], map: "pk_inventory_receipts_line", clustered: false)
}

return await this.prisma.inventory_receipts_hdr.findUnique({
      where: {
        receipt_number: receiptId,
      },
      include: {
        inventory_receipts_line: true,
      },
    });
  }

Environment & setup

• OS: MacOS
• Database: Microsoft SQL Server
• Node.js version: v18.6.0

Prisma Version

Environment variables loaded from .env
prisma                  : 4.3.1
@prisma/client          : 4.3.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt c875e43600dfe042452e0b868f7a48b817b9640b (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.3.0-32.c875e43600dfe042452e0b868f7a48b817b9640b
Default Engines Hash    : c875e43600dfe042452e0b868f7a48b817b9640b
Studio                  : 0.473.0

[comsma]

That seemed to fix it I also added a map key.

inventory_receipts_hdr inventory_receipts_hdr @relation(fields: [receipt_number], references: [receipt_number], onUpdate: NoAction, map: "fk_inv_rcpt_line_inv_rcpt_hdr")

[janpio]

Befrore we spend more time on this: This could already be fixed in dev versions of 4.4.0, see https://github.com/prisma/prisma/issues/15079 and https://github.com/prisma/prisma/issues/14703. Can you try installing prisma@dev and @prisma/client@dev in your project and see if this fixes the query in question? Then this fix would be included in the release next Tuesday.