fix: node 23 support

[FGoessler]

This PR resolves #25463 and thereby introduces support for node.js 23.

Reason for the failure was the use of a deprecated node.js api. See nodejs/node#52744.
I assume this was also just an import error in the first place as we use an internal isError helper function everywhere else in the codebase.

[jkomyno]

Good catch!

Let's fix the failing test https://github.com/prisma/prisma/actions/runs/12600363914/job/35119300223?pr=25971 before merging.

[FGoessler]

I dug into these memory tests and my conclusion is that the updates in node.js v23 change the V8 JIT compiler and optimization behavior. It now either kicks in way later or performs additional optimizations only after a lot of executions which slightly increase the memory footprint due to the additional generated compiled code.

Note

Usually we run 1k iterations per test plus 200 "warmup iterations".

Why do I believe this is the case?

Running the memory profiler over a longer set of runs (~10k runs in the below) shows some spikes of additional and not freed memory during the first 500 to 1500 iterations. All in compiled code and system categories:

Note

Bar heights indicate amount of allocated memory. The grey part was freed again. Blue parts means it is still active and not garbage collected at the the end of the recording.

Compare this to a a node 22 run of the same tests:

Running the tests with the --jitless flag instantly stabilizes them. The memory profiler also shows this nicely:

Heap Timeline Files for the record:
heap-timelines.zip

How can we fix this for these tests?

• A) Increase the number of warmup iterations.
• B) Run the memory tests with the --jitless flag.

For now I choose Option A) as it more closely mimics production behavior, althought it slightly increases test runtimes.