Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vitest hangs with stubbed process #5390

Closed
6 tasks done
tkalmar opened this issue Mar 15, 2024 · 3 comments · Fixed by tinylibs/tinypool#83 or #5430
Closed
6 tasks done

vitest hangs with stubbed process #5390

tkalmar opened this issue Mar 15, 2024 · 3 comments · Fixed by tinylibs/tinypool#83 or #5430
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)

Comments

@tkalmar
Copy link

tkalmar commented Mar 15, 2024

Describe the bug

Vitest hangs ( npx vitest run) if a test stubs the global process.
After updating vitest from 0.34 to 1.4.0
The culprit is the stubbed process, if removed everything works as expected.

Reproduction

vi.stubGlobal('process', { server: false, client: true });

describe('reproducer', () => {
  it('should not hang', () => {
    expect(undefined).toBeUndefined();
  });
});

System Info

System:
    OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz
    Memory: 106.68 GB / 125.50 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 18.18.2 - ~/.nvm/versions/node/v18.18.2/bin/node
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.2/bin/npm
  Browsers:
    Chromium: 122.0.6261.128
  npmPackages:
    @vitest/coverage-istanbul: 0.30.1 => 0.30.1 
    vitest: 1.3.1 => 1.3.1

Used Package Manager

npm

Validations

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Mar 17, 2024

I don't know how far we can allow manipulating globals, but for this specific case of process, the minimal reproduction seems to be process.memoryUsage:
https://stackblitz.com/edit/vitest-dev-vitest-khv9rc?file=test%2Fbasic.test.ts

process.memoryUsage = undefined;

I'm guessing that memoryUsage is used by tinypools and it's throwing inside this try/catch, so no result is coming back:

https://github.com/tinylibs/tinypool/blob/6ca7bb480a9d0c54dac04eaab5e6523d300f1791/src/entry/worker.ts#L126-L135

For your case, I understand it turns out to be a regression, but maybe you could also do:

vi.stubGlobal('process', { ...process, server: false, client: true });

Or stubGlobal is mostly equivalently just process.server = false etc... so you could simply mutate the global by yourselves.

@hi-ogawa hi-ogawa added p3-minor-bug An edge case that only affects very specific usage (priority) and removed pending triage labels Mar 17, 2024
@AriPerkkio
Copy link
Member

We could store reference of memoryUsage in Tinypool before Vitest's entrypoint is imported. We do similarly in birpc for couple of public APIs: https://github.com/antfu/birpc/blob/72510536cedb301953e0550d884667804d7268d0/src/index.ts#L145-L147

@AriPerkkio
Copy link
Member

tinylibs/tinypool#83 fixes this issue. However there are still some process APIs that need to be saved on Vitest's side if pool: 'forks' is used.

@AriPerkkio AriPerkkio reopened this Mar 25, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Apr 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
None yet
3 participants