Open SunstriderEx opened 10 months ago
The newBrowserRegistry
function's called once for each VU and subscribes to their IterStart
, IterEnd
, Exit
events.
If VU runs in a protocol-level scenario at first, then following code executes in the handleIterEvents
func (IterStart
event):
https://github.com/grafana/xk6-browser/blob/e8b026954fb04d73e035e0b20f67063c245ebcc6/browser/registry.go#L241-L249
The handleExitEvent
function also triggers unsubscribe at the same time:
https://github.com/grafana/xk6-browser/blob/e8b026954fb04d73e035e0b20f67063c245ebcc6/browser/registry.go#L292-L293
30 seconds after a protocol-level scenario finishes VU frees. A browser-level scenario launches, takes this VU, but there is no subscription to IterStart
event anymore, so the browser initialization code is not executed, the errBrowserNotFoundInRegistry
error occures in the getBrowser
function.
I tried to fix this, but I don't see a simple solution to this error. It seems to be by design (there is the unsubscribe_on_non_browser_vu
test), and to fix this behaviour working with VU's events and browser initialization needs to be reviewed.
Or am I wrong, and the problem is simpler?
Brief summary
If browser-level test starts after no-browser (protocol-level) tests, an error in
browser.newContext()
may occur. It happens when browser-level test reuses VU, that was already used for protocol-level test (or simply test withoutBrowserContext
creation).Use case: hybrid load testing, many protocol-level tests and some browser-level ones (for testing ASPX pages with multiple internal requests for example), https://k6.io/docs/using-k6-browser/running-browser-tests/#run-both-browser-level-and-protocol-level-tests-in-a-single-script
k6 version
k6 v0.47.0 (commit/5ceb210056, go1.21.2, windows/amd64)
OS
Windows 10
Docker version and image (if applicable)
No response
Steps to reproduce the problem
Just run following script:
Expected behaviour
All iterations of all tests have to pass without errors.
Actual behaviour
It seems it takes 30 seconds to free VUs used by scenario with
constant-vus
executor. Before that moment browser-level test ramping completely new VUs with no problems forbrowser.newContext()
. But at 31 second browser-level test takes VU that was used for protocol-level test. In each iteration of this reused VU occurs an error when trying to createBrowserContext
(see logs below):Output:
As you can see in output there is
vus_max = 3
, while both protocol-level and browser-level tests configured to use 2 VUs.Therefore, at the moment, browser-level tests cannot be combined with protocol-level tests due to this bug in most cases.