`maxConcurrency` is not respected in `beforeAll`/`afterAll` hooks

[BarrensZeppelin]

Describe the bug

More than maxConcurrency number of hooks can run in parallel.

Reproduction

package.json

{
  "name": "vitest",
  "version": "1.0.0",
  "description": "",
  "license": "ISC",
  "author": "",
  "type": "commonjs",
  "devDependencies": {
    "vitest": "^3.2.4"
  }
}

a.test.js

import { beforeAll, describe, it } from 'vitest';

async function sleep(ms=1000) {
    return new Promise(resolve => setTimeout(resolve, ms));
}

describe.concurrent('Test Suite', () => {
    describe.for(["a", "b"])('$0', (name) => {
        beforeAll(async () => {
            console.log(`Running beforeAll for ${name}`);
            await sleep();
        });

        it(`test ${name} 1`, async () => {
        });
    });
});

$ npm exec -- vitest run --max-concurrency=1 a.test.js

 RUN  v3.2.4 <snip>

stdout | a.test.js > Test Suite > 'b'
Running beforeAll for a
Running beforeAll for b

 ✓ a.test.js (2 tests) 1008ms
   ✓ Test Suite > 'a' > test a 1 2ms
   ✓ Test Suite > 'b' > test b 1 0ms

 Test Files  1 passed (1)
      Tests  2 passed (2)
   Start at  09:50:21
   Duration  1.26s (transform 17ms, setup 0ms, collect 12ms, tests 1.01s, environment 0ms, prepare 59ms)

I would expect the test to run for at least 2 seconds, because the calls to sleep should not be run in parallel with --max-concurrency=1.

System Info

Not relevant

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.

[kim-sung-jee]

Hi @sheremet-va, I'd like to work on this issue.

From my analysis, the root cause seems to be that the concurrency limit is only enforced when running individual tests (runTest), but not for the execution of suite lifecycle hooks like beforeAll and afterAll. This is why hooks from different suites can run in parallel, ignoring the maxConcurrency setting.

My proposed solution is to apply the same concurrency limit that is already used for runTest to the hook execution within callSuiteHook. This would ensure that both tests and their setup hooks (like beforeAll) respect the maxConcurrency setting through a shared throttle.

I understand this might create a contention between hooks and tests for the same resource, but it directly addresses the issue of hooks ignoring the concurrency limit. I'm open to discussing potential side effects and alternative approaches.

[BarrensZeppelin]

My proposed solution is to apply the same concurrency limit that is already used for runTest to the hook execution within callSuiteHook. This would ensure that both tests and their setup hooks (like beforeAll) respect the maxConcurrency setting through a shared throttle.

I understand this might create a contention between hooks and tests for the same resource, but it directly addresses the issue of hooks ignoring the concurrency limit. I'm open to discussing potential side effects and alternative approaches.

@kim-sung-jee The proposed solution matches the behaviour I expected. 🙂

[sheremet-va]

My proposed solution is to apply the same concurrency limit that is already used for runTest to the hook execution within callSuiteHook. This would ensure that both tests and their setup hooks (like beforeAll) respect the maxConcurrency setting through a shared throttle.

That is the solution I would expect, yeah. Feel free to work on this