prisma: Intermittent P1001 - "Can't reach database server..."

Personally, I gave up using prisma because of this bug. Too unstable for enterprise use.

I also don’t understand why after months no one has considered this

I’m experiencing the same problem using Prisma 4.2.1 with AWS Lamba and RDS Postgres. A few times a day, we will get an error that it can’t reach our database, but nothing in the RDS metrics indicate that the database is doing anything unusual.

I work with @rflorence who commented a while back saying we were running into this error.

We solved this by upgrading our database to a bigger instance. The free memory it had was very low because we were running on a t3.micro RDS instance in AWS. Upgrading to t3.small (or anything other then micro) has solved this issue. The specific metric is “freeable memory” which was very low and it led to random db disconnections in our app. We missed this metric at first because it was consistently low on memory so there was no odd looking spike or dip whenever the errors occurred.

tldr: make sure your db node has a lot of free memory. Hope that might help anyone else who has run into this issue.

● Test suite failed to run

Can't reach database server at `localhost`:`5432`

Please make sure your database server is running at `localhost`:`5432`.

  at startFn (node_modules/@prisma/client/runtime/library.js:101:2598)

Jest has detected the following 1 open handle potentially keeping Jest from exiting:

● CustomGC

  at Runtime._loadModule (node_modules/jest-runtime/build/index.js:985:29)
  at load (node_modules/@prisma/client/runtime/library.js:73:326)
  at node_modules/@prisma/client/runtime/library.js:73:759
  at runInChildSpan (node_modules/@prisma/client/runtime/library.js:70:25817)
  at Fr.loadLibrary (node_modules/@prisma/client/runtime/library.js:73:677)
  at Vt.loadEngine (node_modules/@prisma/client/runtime/library.js:101:557)
  at Vt.instantiateLibrary (node_modules/@prisma/client/runtime/library.js:100:1478)
  at Vt.start (node_modules/@prisma/client/runtime/library.js:101:2081)

In my case individual tests run fine but test suite fails at the end.

This is still an issue. We’re running into this on CI, our dev and prod.

Here’s a sample stack trace:

Invalid `prismaClient.favorites.create()` invocation in
/home/runner/work/official-graphql/official-graphql/graphql/test/_fixtures/favorite-fixture.ts:24:42

  21     longitude: string | null
  22   }
  23 > => {
→ 24   const f = await prismaClient.favorites.create(
Can't reach database server at `localhost`:`5432`

Please make sure your database server is running at `localhost`:`5432`.
 ❯ test/_fixtures/favorite-fixture.ts:24:42
     22|   }
     23| > => {
     24|   const f = await prismaClient.favorites.create({
       |                                          ^
     25|     // @ts-expect-error
     26|     data: fields
 ❯ Zr.handleRequestError node_modules/@prisma/client/runtime/library.js:171:6414
 ❯ Zr.handleAndLogRequestError node_modules/@prisma/client/runtime/library.js:171:5948
 ❯ Zr.request node_modules/@prisma/client/runtime/library.js:171:5786
 ❯ t._request node_modules/@prisma/client/runtime/library.js:174:10455
 ❯ Module.generateFavoriteFixture test/_fixtures/favorite-fixture.ts:24:13
 ❯ Module.generateMatchFixture test/_fixtures/generateMatchFixture.ts:25:21
 ❯ generateMatchFixturesForAllTypes src/resolvers/Relationship.resolver.fn1.spec.ts:304:15

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Serialized Error: {
  "batchRequestIdx": undefined,
  "clientVersion": "4.11.0",
  "code": "P1001",
  "meta": {
    "database_host": "localhost",
    "database_port": 5[432](https://github.com/official-love-guru/official-graphql/actions/runs/4346412281/jobs/7592438006#step:9:433),
  },
}
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯

 Test Files  1 failed | 67 passed | 6 skipped (74)
      Tests  369 passed | 5 skipped | 53 todo ([453](https://github.com/official-love-guru/official-graphql/actions/runs/4346412281/jobs/7592438006#step:9:454))
   Start at  17:57:26
   Duration  512.53s (transform 4.99s, setup 22.52s, collect 278.13s, tests 1010.76s)

We have pool_timeout=0 so it should never time out on connection. There is something rotten in the prisma connection pooling implementation. The test which failed is our most DB heavy test-we have a lot of fixtures and DB calls in there.

Happens constantly on the first request for any Node service. The first request fails every time. Running the same code a second time, without restarting, it works perfectly. This is on a 32GB MacBook Pro M1 running the following:

@prisma/client : 4.4.0 prisma 4.4.0 node 16.17.0 macos 12.6 docker 20.10.17, build 100c701 docker compose 2.10.2

Have not looked into it, but it almost feels like the PrismaClient is using some type of singleton pattern and throwing the error prior to some underlying piece initializing. That could explain why subsequent calls succeed.