Using invalid connection string parameters leads to suboptimal error message with Node-API library

[janpio]

Using a Postgres connection string with an invalid parameter (e.g. ?pool_timeout=foo) leads to an error message.

This is the error message for generator.engineType=binary (and current default):

C:\Users\Jan\Documents\throwaway\undici4>node script.js      
PrismaClientInitializationError3 [PrismaClientInitializationError]: 
Invalid `prisma.user.findMany()` invocation:


  The provided database string is invalid. The provided arguments are not supported in database URL. Please refer to the documentation in https://www.prisma.io/docs/reference/database-reference/connection-urls for constructing a correct connection string. In some cases, certain characters must be escaped. Please check the string for any illegal characters.
    at cb (C:\Users\Jan\Documents\throwaway\undici4\node_modules\@prisma\client\runtime\index.js:40513:17)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async main (C:\Users\Jan\Documents\throwaway\undici4\script.js:18:11) {
  clientVersion: '2.30.0-integration-undici-4.1',
  errorCode: undefined
}

This is the same error message for generator.engineType=library:

C:\Users\Jan\Documents\throwaway\undici4>node script.js
(node:26436) UnhandledPromiseRejectionWarning: Error: {"is_panic":false,"message":"Error in connector: The provided arguments are not supported","backtrace":"   0: napi_register_module_v1\n   1: napi_register_module_v1\n   2: napi_register_module_v1\n   3: <unknown>\n   4: <unknown>\n   5: <unknown>\n   6: <unknown>\n   7: <unknown>\n   8: <unknown>\n   9: napi_register_module_v1\n  10: napi_register_module_v1\n  11: napi_register_module_v1\n  12: napi_register_module_v1\n  13: napi_register_module_v1\n  14: napi_register_module_v1\n  15: napi_register_module_v1\n  16: napi_register_module_v1\n  17: napi_register_module_v1\n  18: napi_register_module_v1\n  19: napi_register_module_v1\n  20: BaseThreadInitThunk\n  21: RtlUserThreadStart\n"}
(Use `node --trace-warnings ...` to show where the warning was created)
(node:26436) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:26436) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

@pimeys had this to say:

yeah so this error comes from the node api layer
it should be catched
the error data is in json format in the message
it's still coming from quaint
so if you catch that, then parse the json and convert that to a proper error in javascript, we're good

We should also add a test for this.

[williamluke4]

So I've just had a look at this and @pimeys is correct the error was not handled correctly in javascript. I will open a PR to sort this out but there is an additional issue in that the Binary Engine throws the following error when the provided database URL is invalid

{
  "is_panic":false,
  "message": "The provided database string is invalid. The provided arguments are not supported in database URL. Please refer to the documentation in https://www.prisma.io/docs/reference/database-reference/connection-urls for constructing a correct connection string. In some cases, certain characters must be escaped. Please check the string for any illegal characters.",
  "meta":{
    "details":"The provided arguments are not supported in database URL. Please refer to the documentation in https://www.prisma.io/docs/reference/database-reference/connection-urls for constructing a correct connection string. In some cases, certain characters must be escaped. Please check the string for any illegal characters."
  },
  "error_code":"P1013"
}

Whereas the library produces the following

{
  is_panic: false,
  message: "Error in connector: The provided arguments are not supported",
  backtrace:
    "   0: user_facing_errors::Error::new_non_panic_with_current_backtrace\n   1: query_engine::error::<impl core::convert::From<query_engine::error::ApiError> for user_facing_errors::Error>::from\n   2: query_engine::error::<impl core::convert::From<query_engine::error::ApiError> for napi::error::Error>::from\n   3: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll\n   4: tokio::runtime::task::core::CoreStage<T>::poll\n   5: tokio::runtime::task::harness::poll_future\n   6: tokio::runtime::task::harness::Harness<T,S>::poll\n   7: std::thread::local::LocalKey<T>::with\n   8: tokio::runtime::thread_pool::worker::Context::run_task\n   9: tokio::runtime::thread_pool::worker::Context::run\n  10: tokio::macros::scoped_tls::ScopedKey<T>::set\n  11: tokio::runtime::thread_pool::worker::run\n  12: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut\n  13: tokio::runtime::task::harness::Harness<T,S>::poll\n  14: std::sys_common::backtrace::__rust_begin_short_backtrace\n  15: core::ops::function::FnOnce::call_once{{vtable.shim}}\n  16: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once\n             at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/alloc/src/boxed.rs:1546:9\n      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once\n             at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/alloc/src/boxed.rs:1546:9\n      std::sys::unix::thread::Thread::new::thread_start\n             at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys/unix/thread.rs:71:17\n  17: start_thread\n  18: clone\n",
}

I would assume that these errors should be the same

[pimeys]

Yeah we miss that one mapping. I'll do that in a PR.

[pimeys]

My side merged.