-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Refactor group()
and check()
tight coupling with the VU.State
#2869
Comments
This was referenced Jan 24, 2023
mstoykov
added a commit
that referenced
this issue
Feb 14, 2023
Before this check was only returning `false` if it also could emit it, and true otherwise. This should rarely be a problem as the same context that is being checked here is the one that interrupts the VM - so no code will be able to run after this. Unfortunately the code checking if it should be emitted is racing with the one that interrupts the VM. So it is possible for the VM to still not be interrupted when a `check` returns a wrong value. It is even possible for more code to be run before the interrupt is actually called. The code still checks the context as this also updates the internal check structure and we don't want to that if the context is done. The above should be changed with #2869 Fixes #2912
mstoykov
added a commit
that referenced
this issue
Mar 6, 2023
Before this check was only returning `false` if it also could emit it, and true otherwise. This should rarely be a problem as the same context that is being checked here is the one that interrupts the VM - so no code will be able to run after this. Unfortunately the code checking if it should be emitted is racing with the one that interrupts the VM. So it is possible for the VM to still not be interrupted when a `check` returns a wrong value. It is even possible for more code to be run before the interrupt is actually called. The code still checks the context as this also updates the internal check structure and we don't want to that if the context is done. The above should be changed with #2869 Fixes #2912
For the record. After an internal discussion, we decided to clean a milestone since the issue was jumping between milestones without completion. Once we determine which milestone it lands, we set the right one. |
mstoykov
added a commit
that referenced
this issue
May 21, 2024
Group and check were tightly coupled between them and also to the end of test summary and the REST API. This this change the tight coupling is removed. Group and check no longer interact with each other while being ran. In order to keep the same end of test summary and REST API behavior the code makes the same aggregation it used to be but *only* based on the metrics emitted by `check` and `group`. There are several breaking changes still in it as a bunch of things are no longer useful, and technically not implementable if we want to remove the tight coupling. The only one that is relevant though is that `lib.State` no longer has `Group`. There are 2 extensions using that and both of them use it to use the "magic" that tight `group` and `check` together. Fixes #2869
mstoykov
added a commit
that referenced
this issue
May 21, 2024
Group and check were tightly coupled between them and also to the end of test summary and the REST API. This change the tight coupling is removed. Group and check no longer interact with each other while being run. In order to keep the same end of test summary and REST API behavior the code makes the same aggregation it used to be but *only* based on the metrics emitted by `check` and `group`. There are several breaking changes still in it as a bunch of things are no longer useful, and technically not implementable if we want to remove the tight coupling. The only one that is relevant though is that `lib.State` no longer has `Group`. There are 2 extensions using that and both of them use it to use the "magic" that tight `group` and `check` together. Fixes #2869
5 tasks
5 tasks
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This tight coupling is preventing us from implementing
group()
andcheck()
purely in JavaScript. It is also preventing us from implementing similar functions, but with better UX (e.g. #1066, #2865) or that work better withasync
/await
(#2848, #2728)The tight coupling can be removed with only a very small loss of efficiency, by just having the
MetricEngine
processcheck
andgroup_duration
metrics as they appear and group them based on theirgroup
tag. Here is what basically needs to be removed:k6/lib/vu_state.go
Lines 41 to 42 in 1d99b0b
k6/lib/runner.go
Lines 71 to 72 in 1d99b0b
k6/js/modules/k6/k6.go
Lines 98 to 104 in 1d99b0b
k6/js/modules/k6/k6.go
Line 169 in 1d99b0b
The text was updated successfully, but these errors were encountered: