Getting "Address already in use" error

Bug description

Since Prisma 2.15, queries (reads and writes) fail from time to time on Heroku with the following stacktrace:

Error Query engine exited with code 1
 in    0: user_facing_errors::Error::new_non_panic_with_current_backtrace
   1: query_engine::error::<impl core::convert::From<query_engine::error::PrismaError> for user_facing_errors::Error>::from
   2: query_engine::error::PrismaError::render_as_json
   3: query_engine::main::main::{{closure}}::{{closure}}
   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   5: std::thread::local::LocalKey<T>::with
   6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   7: async_io::driver::block_on
   8: async_global_executor::reactor::block_on
   9: std::thread::local::LocalKey<T>::with
  10: async_std::task::builder::Builder::blocking
  11: query_engine::main
  12: std::sys_common::backtrace::__rust_begin_short_backtrace
  13: std::rt::lang_start::{{closure}}
  14: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:381:40
      std::panicking::try
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:345:19
      std::panic::catch_unwind
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:396:14
      std::rt::lang_start_internal
             at /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/rt.rs:51:25
  15: main
  16: __libc_start_main
  17: <unknown>
Address already in use (os error 98) 
    /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/core/src/ops/function.rs:259:13 
    /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:381:40 
    /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panicking.rs:345:19 
    /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/panic.rs:396:14 
    /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/rt.rs:51:25 
    node_modules/@prisma/client/runtime/index.js:78469:15 PrismaClientFetcher.request
    internal/process/task_queues.js:93:5 processTicksAndRejections

How to reproduce

Unfortunately I don’t have a proper reproduction pattern. I expect it happens on production environment with high traffic. I also saw the error once on staging environment though,

Prisma information

DB connection URL params used:

postgresql://....?sslmode=verify-full&sslrootcert=db/rds-ca-2019-root.pem&connection_limit=15

Environment & setup

• OS: Debian (on Heroku)
• Database: PostgreSQL 11 (with AWS Aurora)
• Node.js version: v14.15.4
• Prisma version:

@prisma/cli          : 2.16.0
@prisma/client       : 2.16.0
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine a973e24a4e5194f8fe3301bfa7ff982b24f97c05 (at node_modules/@prisma/engines/query-engine-debian-openssl-1.1.x)
Migration Engine     : migration-engine-cli a973e24a4e5194f8fe3301bfa7ff982b24f97c05 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core a973e24a4e5194f8fe3301bfa7ff982b24f97c05 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary        : prisma-fmt a973e24a4e5194f8fe3301bfa7ff982b24f97c05 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Studio               : 0.346.0

[TimPetricola]

Follow-up after 5 days with useUds: true, the error does not appear anymore

[nrxus]

We also saw this starting yesterday in our Heroku deploy. It is a little strange because we had been in 2.15 for about a week now without any problem and it starting failing yesterday. In 3 of our deploys (out of ~6 we did), we saw this error pop up 5 times total.

For what it’s worth, we are doing node clustering with 5 workers per dyno, and each worker gets its own Prisma client. The error seems to only occur when doing a request right after the deploy, probably because the first request is what tries to connect to Prisma.