Too many Prisma clients being started => jest exits with an error code

[killthekitten]

We've been seeing the following error in our tests, and I was assuming it would go away when we add jest-prisma:

 console.warn
      warn(prisma-client) There are already 10 instances of Prisma Client actively running.

      10 |
      11 |   constructor(configService: ConfigService) {
    > 12 |     super({
         |     ^
      13 |       datasources: {
      14 |         db: { url: <string>configService.get<string>('DATABASE_URL') },
      15 |       },

      at zt.checkForTooManyEngines (node_modules/@prisma/client/runtime/library.js:100:664)
      at new LibraryEngine (node_modules/@prisma/client/runtime/library.js:100:495)
      at PrismaService.getEngine (node_modules/@prisma/client/runtime/library.js:177:6129)
      at new PrismaClient (node_modules/@prisma/client/runtime/library.js:177:5713)
      at new PrismaService (prisma/prisma.service.ts:12:5)
      at TestingInjector.instantiateClass (node_modules/@nestjs/core/injector/injector.js:330:19)
      at callback (node_modules/@nestjs/core/injector/injector.js:48:41)
....
Test Suites: 22 passed, 22 total
Tests:       676 passed, 676 total
Snapshots:   0 total
Time:        17.307 s, estimated 25 s

Unfortunately, it still happens, although with a different backtrace:

 ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "warn(prisma-client) This is the 10th instance of Prisma Client being started. Make sure this is intentional.".

      26 |   constructor(config: JestEnvironmentConfig, context: EnvironmentContext) {
      27 |     super(config, context);
    > 28 |     this.delegate = new PrismaEnvironmentDelegate(config, context);
         |                         ^
      29 |   }
      30 |
      31 |   override async setup() {

      at console.warn (node_modules/@jest/console/build/BufferedConsole.js:191:10)
      at Dt.checkForTooManyEngines (node_modules/@prisma/client/runtime/library.js:102:893)
      at new Dt (node_modules/@prisma/client/runtime/library.js:102:826)
      at t.getEngine (node_modules/@prisma/client/runtime/library.js:126:5173)
      at new t (node_modules/@prisma/client/runtime/library.js:126:4737)
      at new PrismaEnvironmentDelegate (node_modules/@quramy/jest-prisma-core/lib/delegate.js:19:32)
      at new PrismaEnvironment (test/jestSingleContextEnv.ts:28:25)

The problem seems to be that Prisma never decreases the counter of Client instances. it keeps increasing it forever, and it does so every time PrismaEnvironmentDelegate is instantiated because of this line:

jest-prisma/packages/jest-prisma-core/src/delegate.ts

Line 32 in d962be6

const originalClient = new PrismaClient({

Is there a way to reuse the client between environments?

This happens with the following packages (filtered out irrelevant ones):

    "@prisma/client": "^5.1.1",
    "@quramy/jest-prisma-core": "^1.5.0",
    "@quramy/jest-prisma-node": "^1.5.0",
    "@types/jest": "^29.5.3",
    "@types/node": "16",
    "jest": "^29.6.2",
    "jest-environment-node-single-context": "^29.1.0",
    "jest-mock-extended": "^3.0.5",
    "nock": "^13.3.2",
    "prisma": "^5.1.1",
    "supertest": "^6.3.3",
    "ts-jest": "^29.1.1",
    "ts-loader": "^9.4.4",
    "ts-node": "^10.9.1",
    "tsconfig-paths": "^4.2.0",
    "typescript": "^5.1.6"

I would be happy to keep looking for a workaround, but I'd be grateful for a nudge in the right direction. I lack the following to continue:

• How often does PrismaEnvironmentDelegate gets created? Is it per test suite? Is it done in parallel?
• Is there a way for PrismaEnvironmentDelegate to reuse the same client between instances?
• There's a possibility that some of our tests are still not stubbed given that we use Nest's Dependency Injection. Is there an easy way to find the places where that one gets instantiated? I tried throwing from the constructor, but it didn't fail any of the tests.
• Log message implies this happens after the tests are done. Is it because of buffering, or because of a test that is not properly awaited?

In any case, thanks for all the effort that went into this package, apart from this it works like a charm!