process.env.VITEST_WORKER_ID can be larger than maxThreads

[flunderpero]

Describe the bug

We are migrating our Jest test code over to vitest. We use process.env.JEST_WORKER_ID to allocate a separate database for each worker/thread. With Jest that JEST_WORKER_ID is always between 1 and the maximum number of workers.

In vitest process.env.VITEST_WORKER_ID seems to have another meaning and is ever increasing. The documentation states that VITEST_WORKER_ID can be used to distinguish between threads. In my opinion this is not what it actually does.

Reproduction

Run any test-sutie and see that VITEST_WORKER_ID increases. In watch-mode it increases with each run.

System Info

System:
    OS: macOS 12.4
    CPU: (10) arm64 Apple M1 Max
    Memory: 1.36 GB / 64.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
    Yarn: 3.1.0 - ~/.nvm/versions/node/v16.13.1/bin/yarn
    npm: 8.10.0 - ~/.nvm/versions/node/v16.13.1/bin/npm
  Browsers:
    Chrome: 102.0.5005.115
    Firefox: 100.0.2
    Safari: 15.5
  npmPackages:
    vitest: 0.14.2 => 0.14.2

Used Package Manager

yarn

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.

[sheremet-va]

We have a different implementation for workers then Jest. Each spec file fires a different worker (unlike Jest), so for each one you get a number. When watch is triggered, a new worker is created with a unique number. minThreads/maxThreads is passed down to tinypool, and is not used in the calculations.

[flunderpero]

I totally get the idea behind this. Is there any way to get an id based on maxThreads so that we can use it in the way we used JEST_WORKER_ID or is this something you do not see any value in. (I certainly see a lot of value in it. :-) )

[sheremet-va]

Can you describe how you see it? Is it just ID % maxThreads?

[flunderpero]

Since VITEST_WORKER_ID starts at 1 it would have to be ((VITEST_WORKER_ID - 1) % maxThreads) + 1. For our purposes it would be enough to have maxThreads available somehow, so we can make the calculation ourselves. Perhaps it would be a good idea to make it clear in the documentation how VITEST_WORKER_ID works. vitest mimics the API of jest and others might equate VITEST_WORKER_ID with JEST_WORKER_ID (like I did).

[sheremet-va]

#1473 introduces VITEST_POOL_ID with the logic you described

[sheremet-va]

Beware that it will still change when editing file with watch (but not greater than maxThreads). Is it desirable behaviour?

[flunderpero]

Wow, that was quick! It's ok for me that it may change. Thank you!

[flunderpero]

I am afraid that the current implementation (and my suggestion here is wrong.

Imagine a use case where you have maxThreads=3 because you have 3 test databases that you want to use for 3 concurrently running tests. Now imagine the following run order:

VITEST_WORKER_ID -> VITEST_POOL_ID
Start 1                              1
Start 2                             2
Start 3                             3
End 2
Start 4                             1 !!!

In this scenario you have two threads with the same VITEST_POOL_ID and as a result two tests are using the same database. vitest would have to use some sort of bookkeeping to assign only "free" ids to VITEST_POOL_ID.

As a side note: The documentation already references VITEST_POOL_ID even though it is not released yet.

[sheremet-va]

I don't think we have information about when test actually starts and ends. We just fire them all at the same time, and tinypool figures out the rest.

[flunderpero]

Ah, I see. Mhhh, I will look into other possibilities to coordinate my test threads, but it's going to be way more complicated.

I would suggest to revert this change then, because I think it does not help anybody. Thank you again for your swift reaction, I like vitest a lot so far.

[sheremet-va]

Ah, I see. Mhhh, I will look into other possibilities to coordinate my test threads, but it's going to be way more complicated.

I would suggest to revert this change then, because I think it does not help anybody. Thank you again for your swift reaction, I like vitest a lot so far.

We will try to fix this in a few weeks. See #1482

[sheremet-va]

VITEST_POOL_ID should be correct in the next release.

[flunderpero]

Yes, it is!