when running vitest in git action, action exceeded the maximum execution time of xx minutes

[JayKim88]

Describe the bug

I'm not sure it's a direct error or problem of vitest, but to get some help or cues, I report this.

In git action, it fails with the comment as
"The job running on runner GitHub Actions XX has exceeded the maximum execution time of XX minutes."

As shown in the reproduction image, after combineOrders.test.tsx is passed, and it is stuck in the next test spending the whole test time ending up with test fail.

After testing this, I found that this error occurs in case that test tries to find a element by synchronous method such as getByText, getBy-. In local environment, it occurs error as intended if not found.
If I replace these methods with asynchronous method like findby-, it works well locally and in git action.

Are there anybody who experienced this case ?
I hope to know why this happens and how to fix it accordingly. I expect it must make error and fail as soon as it's impossible to find a target element.

Thank you all !

Reproduction

System Info

System:
    OS: macOS 14.4.1
    CPU: (11) arm64 Apple M3 Pro
    Memory: 1.05 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.3.0 - /opt/homebrew/bin/node
    Yarn: 1.22.17 - /opt/homebrew/bin/yarn
    npm: 9.6.7 - /opt/homebrew/bin/npm
    pnpm: 8.6.9 - /opt/homebrew/bin/pnpm
    Watchman: 2023.06.12.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 123.0.6312.107
    Safari: 17.4.1
  npmPackages:
    @vitejs/plugin-basic-ssl: 1.1.0 => 1.1.0 
    @vitejs/plugin-react-swc: 3.6.0 => 3.6.0 
    vite: 5.1.1 => 5.1.1 
    vitest: 1.4.0 => 1.4.0

Used Package Manager

pnpm

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.

[hi-ogawa]

test tries to find a element by synchronous method such as getByText, getBy

I suppose you're talking about some sort of testing library. Can you provide links where these API are coming from?

[JayKim88]

@hi-ogawa Ah yes it is. This is react testing library..! Thank you : )
https://testing-library.com/

[hi-ogawa]

Can you point to exact page or code where they show synchronous version getBy... and async version findby...?

[JayKim88]

This is the page explaining related APIs.
https://testing-library.com/docs/react-testing-library/cheatsheet/#queries

[hi-ogawa]

Thanks for the links.

I don't know your specific test setup, but I think your question should be asked to testing-library team. The reason why synchronous version makes CI stuck is not something we can answer or investigate from the information provided so far (meaning we need a reproduction).

Probably asynchronous version is simply more robust (with automatic timeout), so I suppose it's better to go with that.

[JayKim88]

Thank you for your ideas and suggestion-.
I will check this issue in testing-library repo accordingly 🙏

[gynt]

Thank you for your ideas and suggestion-. I will check this issue in testing-library repo accordingly 🙏

@JayKim88 Did you find a solution?

[anilanar]

If using pnpm, the issue is that pnpm's isolation sets NODE_PATH before running vitest's own bin, which then prevents vitest from being able to clean up browser instance, most likely because of vitest relying on module identity of some module that has module-level state, meaning if that module is loaded twice from different paths, vitest fails to clean up the browser, and then the process hangs.

One workaround is running node node_modules/vitest/vitest.mjs run...