Vitest hangs tests, close timed out after 1000ms #2008
Comments
|
I can confirm the same issue but with pnpm and within a windows github action matrix. |
|
Not sure why it happens in this case, but you can increase timeout with |
|
@sheremet-va, the timeout makes no difference, we have increased it to really high amounts and still had the same issue. This is really slowing down our pipeline and our local workflows, is there any way we can help to troubleshoot or debug? Not even sure where to start. |
It means you start some process and don't end it. Check you websocket/DB/playwright connections. |
|
Not sure what process we could be opening inside that very minimal repo, just using standard libraries for react development, in our real scenario, we are only testing frontend code without any Websockets or DB connections. I'm attaching the log from Any further guidance on where to look for issues will be greatly appreciated! Thank you for your time and the hard work you are doing here, I really really like vitest. |
The repro is fixed, if I increase timeout there. You are saying it didn't work for your project.
I'm also not sure what it means, but thanks for the way to check it -- I didn't know about this method 😄 |
|
@sheremet-va Still seeing the issue, looking for forward guidance if you have any. What I've tried so far:
It seems like there is in fact an open child process that didn't exit, however, I'm not sure what could be spawning it, we are using a very small set of libraries, I'm trying to reproduce the same on StackBlitz but no luck so far. Process list (not sure if this helps or not) |
|
After experimenting a little bit more, we found that disabling threads decreases significantly the chances of getting this error, not sure if this can provide guidance as to what could be failing, this is at least some mitigation for our local workflows and pipeline. We manually need to cleanup after |
|
Same problem on Github Action with Node.js >= 16 https://github.com/node-modules/urllib/actions/runs/3122054130/jobs/5063741291
|
Add |
Part of request #27556: Migrate Vite-based packages to Vitest project-sidebar-internal's JS unit tests get stuck from time to time. It's been reproduced locally but it does not trigger always. An issue comment [0] on vitest's github advises to disable threads to mitigate the issue. We are going to try that. [0]: vitest-dev/vitest#2008 (comment) Change-Id: I4ae7344745b4f4d8ac30b5a21113e461690d0d5e
|
Any movement on this? Our CI is blocked at the moment. |
Zero movement. This is not a global problem, it's not reproducible to everyone. If you get this error even with hight |
|
We're experiencing the same issue. Setting All of our tests are simple unit tests (99% synchronous). There are no open DB/Playwright/websocket processes that could be causing the hang. |
|
@JoshuaToenyes same here! no hanging process for me and get the same error. |
|
Seeing this "close timed out after 1000ms" message on Drone CI as well. Test run still succeeds, and all tests are very simple unit tests, nothing fancy, nothing that would keep the event loop alive so I assume any open handles must be inside vitest itself. Does unfortunately not reproduce locally, even with |
|
Curious if others are also using |
@vidarc I don't think it's related to coverage. We use It could be related to the Node.js version, though. I haven't tried with Node.js < 18 or 19. |
|
For me, it was on Node 18 with no coverage enabled. |
|
This is also not working as correct in our Github Action workflow. Some of our tests fail, but the |
@vidarc @JoshuaToenyes I'm on Node 16, and I started to have this problem when I added |
|
I happen to have one case where it reproduces locally, in a around 1 in 10 runs. When it happens, the node process goes to 100% cpu and hangs forever. I managed to hook up the inspector:
|
|
Very good find, @silverwind! Could you perhaps share how you managed to attach the inspector? I would love to help get to the bottom of this, as it's also blocking my CI. |
|
Just BTW the tests I reproduced this with are doing a bit fancy stuff like starting/stopping a HTTP server, so I think it's definitely possibly that in this case it's not a bug in vite itself, but it still smells like one because the exact same tests run fine in |
|
We had a similar problem on our CI - Vitest tests completed successfully, but sometimes the process would not stop after that and the whole job would hang until it closed by timeout. I made a script like this: // vitest_ci.mjs
import 'zx/globals';
import psList from 'ps-list';
setTimeout(async () => {
console.log(await psList())
$`exit`
}, 2 * 60 * 1000)
try {
await $`yarn vitest run`;
} catch (p) {
$`exit ${p.exitCode}`;
}and used it instead of I then ran the CI several times until I caught the hang. In the list of processes I saw This looks like the problem from this esbuild issue and it was fixed in version 0.16.3 - two weeks ago The latest version of Vitest uses UPD: |
|
Does anybody have any updates about this issue? I tried all solutions from this issue and did not succeed. |
So far there are only two known cases that can cause this. Both can be fixed by using
There are also some mentions about main thread hanging when third party Vite plugins are used: #2008 (comment). I have not been able to reproduce this. |
|
@AriPerkkio what about the reproduction I've put together in the comment above? I seem to be getting this issue, but its not related to any of the cases you've outlined |
That project is failing with Please file a separate issue about that error and let's keep this issue for discussing about |
What were you testing with these options? I am having issues using those options with the Testing Library. If I set |
It looks like there's an issue with vitest/node/fetch/msw that sometimes causes our CI tests to hang. See: vitest-dev/vitest#2008 (comment) We use --pool=forks for the packages that consume the msw tests, but that required that we upgrade vitest. The upgrade of vitest required some snapshot regeneration to remove double encoding, and also some small changes around esm vs cjs file extensions.
|
For me, this happens for any project that is not the first in the |
sheremet-va
added
p4-important
|
In our case, we had one component that was causing the hang. Since there isn't very actionable messages about what causes the hang, we instead were able to track down which specific test suite caused the hang with the following bash script #!/bin/bash
find ./src -type f \( -name "*.test.ts" -o -name "*.test.tsx" \) | while read current_file; do
echo "Running tests for $current_file"
yarn vitest run --mode development "$current_file"
doneIt will still hang, but you'll know which suite it is. Posting in case this is useful to anyone else, It's pretty easy to debug from there (or work around with mocks). Obviously, that will only find the first test suite to hang if there are multiple. |
|
To remove timeout after tests, add |
|
Does anybody know if it's possible to just forcefully kill the hanging workers when all tests pass? |
There's
But as explained on the description of nodejs/undici#2026 and shown on the
We are planning to make |
|
Should retest with Node v21.7.1 as per nodejs/undici#2026 (comment). |
|
I have pretty similar issue. I noticed that test freezes in specified test, but I see no difference how this test is different from others and why especially this one freezes.
export const relations: FindOptionsRelations<HistoryTrack> = {
user: true,
}
export const order: FindOptionsOrder<HistoryTrack> = {
playedAt: 'DESC',
}
@Injectable()
export class HistoryTracksRepository extends Repository<HistoryTrack> {
constructor(
private readonly dataSource: DataSource,
private readonly tracksRepository: TracksRepository
) {
super(HistoryTrack, dataSource.createEntityManager())
}
findHistoryTracksByUser(userId: string) {
return this.find({
where: {
user: {
id: userId,
},
},
relations,
order,
})
}
findLastHistoryTrackByUser(userId: string) {
return this.findOne({
where: {
user: {
id: userId,
},
},
relations,
order,
})
}
createHistoryTrack(newHistoryTrack: CreateHistoryTrack) {
const historyTrack = this.create(newHistoryTrack)
return this.save(historyTrack)
}
}
describe.skip('HistoryTracksRepository', () => {
const userId = 'userId'
let historyTracksRepository: HistoryTracksRepository
let historyTrackMock: DeepMockProxy<HistoryTrack>
let historyTracksMock: DeepMockProxy<HistoryTrack[]>
beforeEach(async () => {
const module = await Test.createTestingModule({
providers: [
{
provide: DataSource,
useValue: {
createEntityManager: vi.fn(),
},
},
{
provide: TracksRepository,
useValue: {
findOrCreateTrackFromExternalId: vi.fn(),
},
},
HistoryTracksRepository,
],
}).compile()
historyTracksRepository = module.get(HistoryTracksRepository)
historyTrackMock = mockDeep<HistoryTrack>({
track: trackEntityMock,
})
historyTracksMock = [historyTrackMock]
})
test('should be defined', () => {
expect(historyTracksRepository).toBeDefined()
})
test('should find history tracks by user', async () => {
const findSpy = vi
.spyOn(historyTracksRepository, 'find')
.mockResolvedValue(historyTracksMock)
expect(
await historyTracksRepository.findHistoryTracksByUser(userId)
).toEqual(historyTracksMock)
expect(findSpy).toHaveBeenCalledWith({
where: {
user: {
id: userId,
},
},
relations,
order,
})
})
test('should find last history track by user', async () => {
const findOneSpy = vi
.spyOn(historyTracksRepository, 'findOne')
.mockResolvedValue(historyTrackMock)
expect(
await historyTracksRepository.findLastHistoryTrackByUser(userId)
).toEqual(historyTrackMock)
expect(findOneSpy).toHaveBeenCalledWith({
where: {
user: {
id: userId,
},
},
relations,
order,
})
})
})Every test excluding |
|
So in my case the issue was caused by using |
|
Л |
CI sometimes still hangs, trying to run without threads - vitest-dev/vitest#2008
CI sometimes still hangs, trying to run without threads - vitest-dev/vitest#2008
CI sometimes still hangs, trying to run without threads - vitest-dev/vitest#2008 - vitest-dev/vitest#3077 In earlier vitest versions the optinon was --no-threads, but this changed to --pool=forks in: - https://github.com/vitest-dev/vitest/releases/tag/v1.0.0-beta.0 - https://github.com/vitest-dev/vitest/blob/main/docs/guide/migration.md#pools-are-standardized-4172 i# with '#' will be ignored, and an empty message aborts the commit.
CI sometimes still hangs, trying to run without threads - vitest-dev/vitest#2008 - vitest-dev/vitest#3077 In earlier vitest versions the optinon was --no-threads, but this changed to --pool=forks in: - https://github.com/vitest-dev/vitest/releases/tag/v1.0.0-beta.0 - https://github.com/vitest-dev/vitest/blob/main/docs/guide/migration.md#pools-are-standardized-4172 Changed vitest config, so that CI and make webtest are both using a single thread.
and others
Describe the bug
Started encountering our tests hanging with the message
close timed out after 1000ms, a google search lead to this issue, tried everything in there with no success, for us is still hit or miss whether we get the error on not.We get the error on different machines and also CI.
Reproduction
https://stackblitz.com/edit/vitejs-vite-brwl54?file=package.json
System Info
System: OS: macOS 12.4 CPU: (10) arm64 Apple M1 Pro Memory: 133.73 MB / 16.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node Yarn: 3.2.0 - ~/.nvm/versions/node/v16.14.0/bin/yarn npm: 8.9.0 - ~/.nvm/versions/node/v16.14.0/bin/npm Browsers: Chrome: 105.0.5195.102 Firefox: 101.0.1 Safari: 15.5Used Package Manager
npm
Validations
The text was updated successfully, but these errors were encountered: