[vitest-worker]: Timeout calling "onTaskUpdate" #6511

vlzuiev · 2024-09-12T09:17:10Z

vlzuiev
Sep 12, 2024

Describe the bug

We're facing the following issue when running vitests on CI (Jenkins).
It's now reproducible locally. All tests are passing.

Any thoughts on why this issue might appear?

⎯⎯⎯⎯ Unhandled Rejection ⎯⎯⎯⎯⎯
Error: [vitest-worker]: Timeout calling "onTaskUpdate"
❯ Object.onTimeoutError ../node_modules/vitest/dist/chunks/rpc.B7Mfb-Yf.js:69:17
❯ Timeout._onTimeout ../node_modules/vitest/dist/chunks/index.BpSiYbpB.js:41:41
❯ listOnTimeout node:internal/timers:581:17
❯ processTimers node:internal/timers:519:7

Reproduction

The issue is not reproducible locally only on CI.

System Info

AWS ECS agent

vitest configration:

test: {
    environment: 'jsdom',
    globals: true,
    retry: isCi ? 2 : 0,
    setupFiles: './src/setupTests.ts',
    testTimeout: 150_000,
    silent: process.env.CI === 'true'
  }

Used Package Manager

npm

Validations

Follow our Code of Conduct
Read the Contributing Guidelines.
Read the docs.
Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
The provided reproduction is a minimal reproducible example of the bug.

nazarhussain · 2025-04-04T13:08:52Z

nazarhussain
Apr 4, 2025

My observation is that RPC timer in birpc starts when the test suit is initialized, not when tasks are started executing. I observed that if one suit is queued but rest of the suits take more time than testTimout then get following error.

0 replies

jacobshirley · 2025-04-12T09:31:40Z

jacobshirley
Apr 12, 2025

Have been experiencing this a lot lately. I use Bazel to execute Vitest. Only happens on CI (Github Actions)

0 replies

greggjs · 2025-04-23T17:27:18Z

greggjs
Apr 23, 2025

I can reproduce this issue locally when sharding out my tests across multiple terminal sessions and I have found that it occurs more frequently when a shard has a test file that has a large number of tests contained within it (like over 30).

0 replies

maroqijalil · 2025-04-24T03:45:52Z

maroqijalil
Apr 24, 2025

I can reproduce the scenario locally under stressed conditions and found that when a test file runs for longer than a certain duration (around 1 minute), the error is triggered.

Splitting the tests in that file into multiple files resolved the issue in my case.

0 replies

kris-ellery · 2025-05-07T23:22:03Z

kris-ellery
May 7, 2025

I'm seeing it at least 2-3 times per day in GitLab CI. I have 155 test suites with 975 tests. Passes locally w/out any issues on Apple silicon MacBook, but CI is very unreliable. Any ideas on how to fix this?

⎯⎯⎯⎯⎯⎯ Unhandled Errors ⎯⎯⎯⎯⎯⎯
Vitest caught 1 unhandled error during the test run.
This might cause false positive tests. Resolve unhandled errors to make sure your tests are not affected.
⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯
Error: [vitest-worker]: Timeout calling "onTaskUpdate"
 ❯ Object.onTimeoutError node_modules/.pnpm/[email protected]_@[email protected]_@[email protected]_@[email protected][email protected]_jiti@_kvzzvg25pb4uej4qh54xdkvdle/node_modules/vitest/dist/chunks/rpc.DGgL5dw7.js:62:10
 ❯ Timeout._onTimeout node_modules/.pnpm/[email protected]_@[email protected]_@[email protected]_@[email protected][email protected]_jiti@_kvzzvg25pb4uej4qh54xdkvdle/node_modules/vitest/dist/chunks/index.68735LiX.js:55:41
 ❯ listOnTimeout node:internal/timers:[588](RETRACTED/-/jobs/60018627#L588):17
 ❯ processTimers node:internal/timers:523:7

0 replies

dubzzz · 2025-05-13T18:53:47Z

dubzzz
May 13, 2025

I have a very similar issue on the open-source project fast-check (here). The issue started to appear when I attempted to bump from 3.0.9 to 3.1.3 and seems to be related to my spec file Docs.spec.ts and its test called file.md. The issue only happens on CI against Ubuntu with Node 22.

0 replies

RichardKaufmannOG · 2025-05-14T14:10:47Z

RichardKaufmannOG
May 14, 2025

Caution

We also have this issue. Tests seem to work, but afterwards Timeout calling "onTaskUpdate" appears.
We use vitest v3.0.8.

Note

Setting higher values for test-timeout, hook-timeout or teardown-timeout did not change anything.

Tip

Workaround that helped us was originally posted here. Put this into the test file which was executed right before the error appears:

afterEach(async () => {
// already existing afterEach code goes here

 await new Promise(res => setImmediate(res))
});

0 replies

kgetz-arista · 2025-05-14T22:21:48Z

kgetz-arista
May 14, 2025

Also running into this after upgrading Vitest from 3.0.9 to 3.1.3. Also seeing failures in CI (Jenkins) only; tests pass just fine on my laptop.

My solution was to break up a large, long-running test file into smaller test files. That seems to have done the trick (no afterEach workaround necessary).

1 reply

manuel3108 Jun 20, 2025

Also running into this after upgrading Vitest from 3.0.9 to 3.1.3.

Can confirm that downgrading to 3.0.9 fixes it for me as well. All other comments here did not help me resolve this issue

velut · 2025-05-16T14:01:39Z

velut
May 16, 2025

Setting pool to threads instead of the default forks helps in my case.

import { defineConfig } from "vitest/config";

export default defineConfig({
	test: {
		pool: "threads",
	},
});

See https://vitest.dev/config/#pool.

0 replies

mikegreiling · 2025-06-11T16:46:07Z

mikegreiling
Jun 11, 2025

I am also having this issue. I am using pool: vmForks, though switching to vmThreads exhibits the same error.

Even if breaking up large tests is a solution, I'd rather not have to limit my test files to arbitrary size limits. My tests should just work even if they are written sub-optimally. Curious what the underlying cause might be.

0 replies

greggjs · 2025-06-11T16:53:24Z

greggjs
Jun 11, 2025

👋 hey so I thought I'd come back here an update on my situation:

My repository has a ton of emotion based theming, and upon removing the theme provider for emotion, my tests ran 1 second faster per test, and I don't have any worker timeout issues anymore. I would like to say the issue was caused by emotion, but it could also be caused by my company's theme provider that uses emotion, so take it with a grain of salt but it worked for us. So, if you can remove unnecessary things for component tests like theme providers from your tests, it will make this issue go away.

0 replies

mikegreiling · 2025-06-11T17:08:39Z

mikegreiling
Jun 11, 2025

In my case, I have no indication of which test is the culprit. We are running a suite of 6000+ tests which pass just fine in local development, but in CI we get this very frustrating error message at the end of the test suite.

The stack trace is not useful in narrowing anything down. I do not see any output during the test run. It seems as though something is not cleaned up properly, but I have no idea how to go about diagnosing what's happening.

2 replies

ben-clarke Jun 11, 2025

That is possibly because one (or more) of your test files takes longer than 60 seconds to complete. There seems to be a hardcoded timeout that throws this error at the end of the whole suite. I am not sure about the reasoning of throwing an error after 60 seconds or if there even is one - it could just be a finger in the air "timeout after 60 seconds" thing.

I would do some analysis on the timings per file in the output to see if this the case for you. If it is try breaking it/them down and see if it fixes it.

This is what I have seen in the past - however your case may be different.

mikegreiling Jun 11, 2025

Thank you, I think that might have done the trick. I took my two longest-running tests and broke them up into smaller files and that got rid of it (at least it seems to, I've only run a few pipelines since)

It would be great if we could get this error message to be a bit more expositive so others don't run into this same headache. A simple CheckboxTree.test.tsx timed out after 60 seconds would be very welcome here. If I have time I will try to investigate and throw together a pull request.

kinoli · 2025-06-27T22:27:24Z

kinoli
Jun 27, 2025

I ran into this issue as well. Adding the following to vitest.setup file fixed it.

import { flushPromises } from '@vue/test-utils'

afterEach(async () => {
  await flushPromises()
})

You may be able to target the actual large tests that are causing it if you want to localize flushPromises more, but I didn't feel I needed to.

0 replies

Tobbe · 2025-07-06T05:59:29Z

Tobbe
Jul 6, 2025

I'm running into this issue as well. Mostly on Windows CI. Never locally. I'm on Vitest 3.2.4

A lot of the suggestions in this thread is to break larger testfiles up into smaller files.
My problem is that the test file that fails already only has one test in it, so I can't break it down further.

Running that single test file locally these are the timings:

Doesn't seem terribly bad, does it? It is doing some filesystem stuff, so I could look into mocking fs to move more of that to in-memory operations to probably speed it up a little bit more. But I'm not sure that'll actually help fix this issue.

Now trying the await new Promise((res) => setImmediate(res)) workaround posted by @RichardKaufmannOG.
cedarjs/cedar#174

2 replies

Tobbe Jul 6, 2025

The workaround might have worked for that testcase. But now another one is failing with the same error.
Would be really nice to understand what the real issue is here

Tobbe Jul 17, 2025

I was originally putting the workaround in beforeAll, but kept seeing this issue in my CI runs. So I switched to afterEach as the original workaround did. Still errors out from time to time on CI 🙁 Here's an example cedarjs/cedar@222d16a

AriPerkkio · 2025-07-22T19:39:04Z

AriPerkkio
Jul 22, 2025
Maintainer

This is fixed in https://github.com/vitest-dev/vitest/releases/tag/v4.0.0-beta.4 by

fix: prevent rpc timeout on slow thread blocking synchronous methods #8297

10 replies

We understand that some organizations face constraints that prevent immediate upgrades, such as legacy codebases, compliance requirements, or complex dependency chains. If your company cannot upgrade immediately but needs continued security support for Node.js v18 or earlier versions, commercial support is available through HeroDevs.

You can continue to use Node 18 as long as you pay. This is why I do not want to throw away Node 18 immediately in my libraries.

Uh oh!

Uh oh!

[vitest-worker]: Timeout calling "onTaskUpdate" #6511

Uh oh!

Uh oh!

Describe the bug

Reproduction

System Info

Used Package Manager

Validations

Replies: 15 comments · 15 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AriPerkkio Jul 22, 2025 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 15 comments 15 replies

AriPerkkio
Jul 22, 2025
Maintainer