SQL Server: crash using native type @db.UniqueIdentifier: `Conversion failed when converting from a character string to uniqueidentifier.`

Bug description

Even with a very minimal schema.prisma, calling findUnique() on a PrismaClient() causes Node to run out of memory and crash.

How to reproduce

1. I was able to introspect my MS Azure SQL Edge (essentially SQL Server) database, so my database URL is configured correctly.
2. npx prisma generate
3. Add the following to test_prisma.ts:

import { PrismaClient } from "@prisma/client";
const prisma = new PrismaClient();
prisma.background_job_requests
  .findUnique({ where: { id: "123" } })
  .then((d: any) => console.log(`found one :${d}`))
  .catch((e: any) => console.error(e));

1. npx ts-node ./test_prisma.ts

Expected behavior

Script runs and exits without error.

Prisma information

model background_job_requests {
  id         String   @id(map: "PK__backgrou__3213E83F6BC835AF") @default(dbgenerated("newid()"), map: "DF__background_j__id__0BBD6DF4") @db.UniqueIdentifier
  created_at DateTime @db.DateTimeOffset
  job_name   String   @db.VarChar(100)
  args_json  String?  @db.VarChar(Max)
}

Environment & setup

• OS: macOS
• Database: MS Azure SQL Edge (essentially the same as MS SQL Server)
• Node.js version: v14.15.4

Prisma Version

prisma                  : 3.9.0
@prisma/client          : 3.10.0
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : bcc2ff906db47790ee902e7bbc76d7ffb1893009
Studio                  : 0.457.0

[sbleon]

Thanks for responding! I just tried again with consistent version 3.14.0 and a new, almost empty database. The database schema is simply:

create table whatever (id uniqueidentifier primary key, name varchar(50) not null);

I then ran npx prisma db pull, which produced the following in my schema.prisma:

model whatever {
  id   String @id(map: "PK__whatever__3213E83F2799539F") @db.UniqueIdentifier
  name String @db.VarChar(50)
}

My test script:

import { PrismaClient } from "@prisma/client";
const prisma = new PrismaClient();

prisma.whatever
  .findUnique({ where: { id: "123" } })
  .then((d: any) => console.log(`found one :${d}`))
  .catch((e: any) => console.error(e));

When I run the test script with ts-node, I get the OOM crash:

$ npx ts-node -r tsconfig-paths/register src/scripts/test_prisma.ts
<--- Last few GCs --->

[19377:0x150008000]     2404 ms: Scavenge 555.9 (575.5) -> 548.3 (579.7) MB, 2.2 / 0.0 ms  (average mu = 0.980, current mu = 0.980) allocation failure 
[19377:0x150008000]     2417 ms: Scavenge 560.0 (579.7) -> 550.7 (584.0) MB, 1.9 / 0.0 ms  (average mu = 0.980, current mu = 0.980) allocation failure 
[19377:0x150008000]     2434 ms: Scavenge 564.6 (584.2) -> 553.7 (587.2) MB, 1.6 / 0.0 ms  (average mu = 0.980, current mu = 0.980) allocation failure 

<--- JS stacktrace --->

FATAL ERROR: wasm code commit Allocation failed - process out of memory
 1: 0x10241fed0 node::Abort() [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 2: 0x102420034 node::OnFatalError(char const*, char const*) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 3: 0x102538f70 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 4: 0x102538f04 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 5: 0x102ad3e68 v8::internal::wasm::WasmCodeAllocator::AllocateForCodeInRegion(v8::internal::wasm::NativeModule*, unsigned long, v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 6: 0x102ad4af8 v8::internal::wasm::NativeModule::CreateEmptyJumpTableInRegion(int, v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 7: 0x102ad379c v8::internal::wasm::NativeModule::AddCodeSpace(v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 8: 0x102ad4904 v8::internal::wasm::NativeModule::NativeModule(v8::internal::wasm::WasmEngine*, v8::internal::wasm::WasmFeatures const&, v8::internal::VirtualMemory, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, std::__1::shared_ptr<v8::internal::Counters>, std::__1::shared_ptr<v8::internal::wasm::NativeModule>*) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
 9: 0x102ad6e84 v8::internal::wasm::WasmCodeManager::NewNativeModule(v8::internal::wasm::WasmEngine*, v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, unsigned long, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
10: 0x102ae2a30 v8::internal::wasm::WasmEngine::NewNativeModule(v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
11: 0x102aaef3c v8::internal::wasm::CompileToNativeModule(v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, v8::internal::wasm::ErrorThrower*, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, v8::internal::wasm::ModuleWireBytes const&, v8::internal::Handle<v8::internal::FixedArray>*) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
12: 0x102adf7b8 v8::internal::wasm::WasmEngine::SyncCompile(v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, v8::internal::wasm::ErrorThrower*, v8::internal::wasm::ModuleWireBytes const&) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
13: 0x102b06388 v8::(anonymous namespace)::WebAssemblyModule(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
14: 0x1025a2690 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
15: 0x1025a1a00 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<true>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
16: 0x1025a14f8 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/leon/.nodenv/versions/14.15.4/bin/node]
17: 0x102cc050c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/leon/.nodenv/versions/14.15.4/bin/node]
18: 0x102c54cbc Builtins_JSBuiltinsConstructStub [/Users/leon/.nodenv/versions/14.15.4/bin/node]
19: 0x102d3d44c Builtins_ConstructHandler [/Users/leon/.nodenv/versions/14.15.4/bin/node]
20: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
21: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
22: 0x102c54b6c Builtins_JSConstructStubGeneric [/Users/leon/.nodenv/versions/14.15.4/bin/node]
23: 0x102d3d44c Builtins_ConstructHandler [/Users/leon/.nodenv/versions/14.15.4/bin/node]
24: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
25: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
26: 0x102c51f44 Builtins_ArgumentsAdaptorTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
27: 0x102c54b3c Builtins_JSConstructStubGeneric [/Users/leon/.nodenv/versions/14.15.4/bin/node]
28: 0x102d3d44c Builtins_ConstructHandler [/Users/leon/.nodenv/versions/14.15.4/bin/node]
29: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
30: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
31: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
32: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
33: 0x102c59174 Builtins_InterpreterEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
34: 0x102c56a24 Builtins_JSEntryTrampoline [/Users/leon/.nodenv/versions/14.15.4/bin/node]
35: 0x102c566c8 Builtins_JSEntry [/Users/leon/.nodenv/versions/14.15.4/bin/node]
36: 0x150008000 
error Command failed with signal "SIGABRT".

However, if I compile the TS into JS by running tsc, then running the compiled script produced more reasonable output:

$ node dist/scripts/test_prisma.js
PrismaClientKnownRequestError: 
Invalid `.findUnique()` invocation in
/Users/leon/code/redacted/backend_node/dist/scripts/test_prisma.js:7:6

   4 const client_1 = require("@prisma/client");
   5 const prisma = new client_1.PrismaClient();
   6 prisma.whatever
→  7     .findUnique(
  Inconsistent column data: Conversion failed: Conversion failed when converting from a character string to uniqueidentifier.
    at Object.request (/Users/leon/code/redacted/backend_node/node_modules/@prisma/client/runtime/index.js:45405:15)
    at async PrismaClient._request (/Users/leon/code/redacted/backend_node/node_modules/@prisma/client/runtime/index.js:46301:18) {
  code: 'P2023',
  clientVersion: '3.14.0',
  meta: {
    message: 'Conversion failed: Conversion failed when converting from a character string to uniqueidentifier.'
  }
}
node(19849,0x106a28580) malloc: *** error for object 0x6000038c0780: pointer being freed was not allocated
node(19849,0x106a28580) malloc: *** set a breakpoint in malloc_error_break to debug
[1]    19849 abort      node dist/scripts/test_prisma.js

So I don’t know if this is a ts-node related problem, or a prisma problem, or maybe it’s my version of Node, which needs to be upgraded.

[sbleon]

I was indeed using "123" as the value. I think that prisma should raise an error given an invalid value, not run out of memory and crash.

That said, I’m not currently using prisma, and I’m not personally invested in this issue getting fixed, so if y’all want to close it I’m fine with that.