Vitest crashes when running tests with Prisma #3106
Comments
|
I'm seeing this issue causing intermittent CI failures when running tests with |
|
I have the same issue, removing manual $connect makes the test run "correctly" but there is no obvious reason it should run correctly except than it is silently erroring. |
I made the same observation. It's my assumption that removing the manual connect sometimes allows the test to run correctly because the connection to the database hasn't been established before the rejection is processed. So, the query never really begins executing in this case. I put the connect in the test to ensure that the query has the best chance of executing. |
|
I tested again with prisma 4.12.0 and vitest 0.30.1 and received the same results |
|
have the same issue, hard to spot, so many variations of it. now trying with |
@phifa Yes, quite a big one, especially if you have a decent machine and some longer running async tests. |
|
I tested again with prisma v4.13.0 and vitest v0.31.0 and received similar crashes with the reproduction repo. |
|
Same here, happens with Prisma tests. |
|
Does anyone have a minimal reproduction case that I could run without installing non-Node dependencies, e.g. postgresql? Something as simple as It sounds like Prisma isn't stable when run in |
|
@AriPerkkio you can adapt my repro to use sqlite instead, I'm pretty sure it also fails. https://github.com/nakleiderer/vitest-crash-reproduction You'll need to change the EDIT: I added a sqlite branch to the repro. |
|
I added a sqlite branch to the repro. It appears that this makes the errors less common. My suspicion is that Prisma's connection cleanup is the culprit and the local sqlite version doesn't experience it as often because it's super easy to cleanup. |
|
Thanks @nakleiderer for reproduction setups. I hadn't noticed that there was a ready-to-use Docker setup for database. I was able to reproduce the issue constantly with that one. Here is minimal reproduction without Vitest. Prisma keeps crashing constantly with errors like:
Save this as import { Worker, isMainThread } from "node:worker_threads";
import { resolve } from "node:path";
import { PrismaClient } from "@prisma/client";
if (isMainThread) {
// Run 10x workers. The crash is noticeable with lower amounts too.
for (const _ of Array(10).fill()) {
new Worker(resolve("./worker.mjs"));
}
} else {
const prisma = new PrismaClient();
await prisma.$connect();
await Promise.all([
prisma.user.count({ where: { id: 1 } }),
Promise.reject(new Error("Oh no!")),
prisma.user.count({ where: { id: 1 } }),
])
// Catching the error does not matter
.catch(() => {});
// Disconnection does not matter
// await prisma.$disconnect();
} |
|
@AriPerkkio Great work! Thank you. I certainly appreciate your time. I'll open a new reproduction and send it over to the Prisma team on this issue prisma/prisma#18577 It seems like this is clearly in the Prisma ballpark now (unless they don't support workers, but we'll find out). Did something change in vitest around v0.24.4 that would have made this issue more noticeable? Is there any configuration available in vitest to disable worker isolation but still allow some concurrency, or is |
|
I would recommend to use import { defineConfig } from 'vitest/config'
export default defineConfig({
test: {
poolMatchGlobs: [
// Run database tests in child_process - Prisma crashes when run in 'node:worker_threads'
['**/database/tests/**', 'child_process'],
]
}
})If Prisma does not support |
|
Thanks for the help investigating this @AriPerkkio. |
|
Vitest 1.0.0-beta has now If the code you are testing is incompatible with |
Describe the bug
NOTE: I'm cross-posting this issue from prisma/prisma#18577 because it's unclear which tool is causing the issue, the bug might require collaboration between vitest and prisma, and for other members of the vitest or prisma communities to be able to search this issue in their respective repositories.
When running tests with Vitest and Prisma, I receive a variety of crashes: segmentation fault, bus error, and abort. Sometimes, Rust is able to print a stack trace before crashing:
Super long debug output and stack trace
In Prisma 4.11, I also received this trace (but was unable to get it again with 4.12):
The issue seems to be related to Vitest's threading features. If you set
test: { threads: false }in thevite.config.ts, the issue no longer occurs (or becomes so rare that I've been unable to find a failure).It's unclear to me if the root cause is in Vitest or Prisma, or perhaps a subtle interaction between the projects. I've tested Prisma v3.15 through 4.12 with Vitest 0.29.8 and received similar crashes. I've tested Vitest 0.24.0 through 0.29.8 and v0.24.4 appears to be the first affected version of vitest.
Potentially related issues:
(left == right)prisma/prisma#17954Reproduction
postgresql://postgres:postgres@localhost:5432/postgres(or change the connection string in
prisma/schema.prisma)npm installandnpx prisma migratenpm test -- --run(for single test run)System Info
System: OS: macOS 13.2.1 (22D68) CPU: (10) arm64 Apple M1 Max Memory: 2.16 GB / 64.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 18.13.0 - ~/.asdf/installs/nodejs/18.13.0/bin/node npm: 8.19.3 - ~/.asdf/plugins/nodejs/shims/npm Browsers: Chrome: 111.0.5563.146 Firefox: 108.0.1 Safari: 16.3 npmPackages: @prisma/client: ^4.12.0 => 4.12.0 prisma: ^4.12.0 => 4.12.0 vitest: ^0.29.8 => 0.29.8Used Package Manager
npm
Validations
The text was updated successfully, but these errors were encountered: