Prisma client silently tries to reconnect to the default URL if a query is sent to a `$disconnect`ed client

Bug description

Once you call prismaClient.$disconnect(), it should be safe to assume that this client is no longer functional without specifying a reconnection logic, however, if one tries to call another query method on the same client, it silently tries to reconnect to the default url set on schema.prisma leading, in some cases ,to an unexpected or misleading error while also compromising application logic (since the client would reconnect without letting the rest of the application know).

How to reproduce

It’s possible to reproduce the issue here https://github.com/TheVoid-0/issue-prisma-reconnect-default-url

however it’s pretty simple:

// set an invalid/empty/fake/mocked url on schema.prisma
// instantiate a client with a custom url
const prismaClient = new PrismaClient({
    datasources: {
      db: { url: 'customUrl' },
    },
  });

// Do any query, it does not matter if it's raw or with models
await prismaClient.$queryRaw`SELECT 1`

// Disconnect the client
await prismaClient.$disconnect();

// Do another query
await prismaClient.$queryRaw`SELECT 1`

Expected behavior

This may not be a bug, but arguably it should at least have an exposed api for the developer tweak/act on the client reconnection logic, for instance, in my application, a reconnection of a client is totally unwanted and I must stop such attempt, I would like to go event further if possible, and say to the client completly destroy itself after disconnection.

Either the client reconnection can be customized, or it shouldn’t be able to reconnect at all.

Prisma information

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["interactiveTransactions"]
}

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


model User {
    id Int                  @id @default(autoincrement())
    name String
    device  Device?
}

model Device {
    id Int                  @id @default(autoincrement())
    type String
    userId Int?             
    user   User?             @relation(fields: [userId], references: [id])
}

Environment & setup

• OS: Windows 10
• Database: MySql
• Node.js version: 16.13.2

Prisma Version

prisma                  : 3.10.0
@prisma/client          : 3.10.0
Current platform        : windows
Query Engine (Node-API) : libquery-engine 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Migration Engine        : migration-engine-cli 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine    : introspection-core 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary           : prisma-fmt 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash    : 73e60b76d394f8d37d8ebd1f8918c79029f0db86
Studio                  : 0.458.0

[willfrew]

I just bumped into this too (using the env var workaround for now).

Just wanted to note that I feel this is still a kind/bug rather than a kind/feature ({ datasource: { url } } not being respected after $disconnect).

For my use-case I’m explicitly disconnecting from the db after some idle time with no db queries (implemented with a middleware) in order to ensure AWS Aurora Serverless can spin down to zero capacity to save costs when not being used.

[janpio]

(The label update here was accidental and now reverted)