There are X handle(s) keeping the process running; FILEHANDLE #4415
Comments
Happy to look into this but we need a reproduction case. |
|
Hello @gajus. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with |
I wouldn't even know where to start. This happens in our large repository with thousands of tests, and doesn't happen every time. |
|
Seeing Tinypool in the listed resources indicates that some test file is preventing it from shutting down. Without What's the reason why you are using |
Without it it just occasionally times out. The test suite never completes. It is not a single file. Keeps popping up on random files, e.g. I am trying to replicate this issue locally. I installed while [ true ]; do vitest run queries/productizedServiceById.test.ts; doneBut so far nothing. |
|
Is it at all possible that this is somehow hardware/OS specific? These tests have ran now at least 50 times on my machine without a single hitch. On CI I keep seeing them fail every other build. Will try to create a VM that replicates the CI env. |
|
Without seeing the test cases, dependencies and Vitest configuration it's impossible to point out the root cause. But here's some things to try at least:
|
|
Starting to suspect that we are hitting this nodejs/undici#2026 |
|
You could try if using |
|
ah, literally just did this a second ago. |
|
Note that you could be hitting nodejs/node#49344. |
This would be only an issue if coverage is enabled, right? We have coverage explicitly disabled in our tests. Our config, for reference: export default defineConfig({
resolve: {
alias: {
'#': path.resolve(__dirname, './test'),
$: path.resolve(__dirname, './testV2'),
'@': path.resolve(__dirname, './src'),
},
},
test: {
coverage: {
enabled: false,
},
environment: 'node',
// Note that we are intentionally using *.test.ts suffix because
// *.test.{ts,tsx} suffix is used by ESLint to identify vitest files.
// Do not add non-*.test.{ts,tsx} files to the list below.
include: ['./{src,test,testV2}/**/*.test.ts'],
maxThreads: isCi ? Math.ceil(os.cpus().length * 0.8) : 4,
minThreads: 1,
mockReset: true,
outputFile: './src/__generated__/vitest/results.xml',
reporters: ['verbose'],
setupFiles: path.resolve(__dirname, './test/vitest.setup.ts'),
testTimeout: 60_000,
},
}); |
|
Something more to try, set UV_USE_IO_URING=0. |
Vitest moved from using |
Describe the bug
This might be not a bug, but where does one even start debugging this?
Reproduction
Running our entire test suite.
System Info
System: OS: macOS 13.2.1 CPU: (10) arm64 Apple M1 Max Memory: 955.88 MB / 64.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 21.1.0 - ~/.nvm/versions/node/v21.1.0/bin/node Yarn: 1.22.19 - ~/Library/pnpm/yarn npm: 10.2.0 - ~/.nvm/versions/node/v21.1.0/bin/npm pnpm: 8.9.0 - ~/.nvm/versions/node/v21.1.0/bin/pnpm Browsers: Brave Browser: 116.1.57.64 Chrome: 118.0.5993.117 Edge: 114.0.1823.43 Safari: 16.3 npmPackages: vitest: ^0.34.5 => 0.34.5Used Package Manager
pnpm
Validations
The text was updated successfully, but these errors were encountered: