fix: workerInitializationDelay is not hardcoded - #5676
Open
kobenguyent wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation/Description of the PR
The standard solutions to the "Thundering Herd" problem with concurrent browser initialization. The previous implementation had a couple of architectural flaws:
same millisecond. This causes a massive CPU usage spike which can starve the main process and actually delay everything downstream.
an arbitrary setTimeout when they reach the code execution phase.
A Better Implementation: Master-Coordinated Staggering
The standard practice in large-scale concurrent runners (like Playwright test and Jest worker-pools) is to stagger the creation of the worker threads themselves in the master process or use a bounded connection pool.
by removing the artificial delay logic from the worker file altogether and instead moved a 200ms delay directly into the worker-creation loop inside lib/workers.js.
• The CPU spike from spawning V8 instances is drastically smoothed out.
Why this is better:
• The master process now creates the first worker, waits 200ms, then creates the second worker, and so on.
• The browser initialization is naturally staggered because each worker starts its entire lifecycle (including imports and setups) exactly 200ms behind the previous one.
• You no longer have hacky math based on workerIndex inside your test runner script.
Users can now specify workerInitializationDelay: in their codecept.conf.js root configuration. If they omit it, it defaults to 200ms, and setting it to 0 will disable the delay entirely.
Here's an example of how a user would use this in their codecept.conf.js:
Type of change
Checklist:
npm run docs)npm run lint)npm test)