vitest 3 finishes green then hangs for 10s and warns about closing Vitest

For the things you open on purpose, use the teardown hooks rather than hoping. globalSetup can return a function that runs at the very end - that is where servers and pools you started deliberately get closed. Anything per-file goes in afterAll in a setup file.

The rule I use: if a test file imports it and it has a close() or end(), something in that file is responsible for calling it.

"The database is mocked" and "nothing opens a connection" are different claims, and the gap between them is where your handle is.

Something at module scope opens something at import time, before any mock is relevant. The usual suspects:

• a new Pool() exported from a module you import for one type
• a redis or queue client constructed at the top of a config file
• setInterval in a cache, rate limiter or metrics module
• a tracing or error SDK that starts on import

Stop guessing and ask node:

node --import why-is-node-running/register ./node_modules/vitest/vitest.mjs run

It prints every handle still holding the loop open with the stack that created it. Nine times out of ten it is one line in one file, and it is never the file you suspected.

The ten seconds is teardownTimeout, which defaults to 10000. People's first instinct is to raise it. Do not - it is the smoke alarm, not the fire. If you raise it to 30s you have simply agreed to wait longer for the same problem.

--pool=forks with isolation on is slower but the leak dies with the fork, so at least the one-in-ten total hang stops while you hunt. Treat it as a tourniquet, not a fix.

Custom reporter with process.exit(0) at the end. Tests passed, who cares what handles are open.

Check for a request mocking server started in setup and never closed. That one bit me and it is invisible because the tests all pass.