Skip to content
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

k6.check: Fix returned values when iteration is ending #2915

Merged
merged 2 commits into from
Mar 6, 2023

Conversation

mstoykov
Copy link
Contributor

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

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
@codecov-commenter
Copy link

codecov-commenter commented Feb 14, 2023

Codecov Report

Merging #2915 (4fde798) into master (a37aec3) will decrease coverage by 0.05%.
The diff coverage is 100.00%.

❗ Current head 4fde798 differs from pull request most recent head 52ac5f3. Consider uploading reports for the commit 52ac5f3 to get more accurate results

@@            Coverage Diff             @@
##           master    #2915      +/-   ##
==========================================
- Coverage   76.92%   76.87%   -0.05%     
==========================================
  Files         225      225              
  Lines       16873    16875       +2     
==========================================
- Hits        12979    12973       -6     
- Misses       3062     3069       +7     
- Partials      832      833       +1     
Flag Coverage Δ
ubuntu 76.82% <100.00%> (+<0.01%) ⬆️
windows 76.69% <100.00%> (-0.05%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
js/modules/k6/k6.go 98.29% <100.00%> (+0.02%) ⬆️
metrics/metric_type.go 78.94% <0.00%> (-3.51%) ⬇️
lib/testutils/minirunner/minirunner.go 74.32% <0.00%> (-2.71%) ⬇️
js/initcontext.go 86.61% <0.00%> (-1.58%) ⬇️
js/modules/k6/ws/ws.go 86.08% <0.00%> (-0.58%) ⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link
Contributor

@imiric imiric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work tracking this issue! 👏

In hindsight, it seems obvious when reading the code, and it's surprising we haven't run into it until now.

Let's merge this after the v0.43.0 relase, so we can test it properly.

Can you share the script and run options you used to reproduce this? Maybe post it in the issue.

@mstoykov
Copy link
Contributor Author

@imiric I have added tests (I needed more stuff than the current tests needed and didn't want to do a whole test refactor for this )

It is the same as the one in the issue I just decreased the length and added gracefulStop as that makes it more likely (given the fix especially). GOMAXPROCS=256 also seems to increase the chances of it being hit.

@na-- na-- added this to the v0.44.0 milestone Feb 20, 2023
@mstoykov mstoykov requested a review from imiric February 27, 2023 15:26
Comment on lines +529 to +534
type testCase struct {
samples chan metrics.SampleContainer
testRuntime *modulestest.Runtime
}

func testCaseRuntime(t testing.TB) *testCase {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems useful, but don't we already have similar helpers? checkTestRuntime() is very similar.

Can we reuse an existing helper, and even better, move it to somewhere where it's usable by other packages? This is a generic helper that I'm sure we're duplicating elsewhere, as this setup boilerplate is very common.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need more stuff than what is available in checkTestRuntime - specifically cancelling the context.

I really didn't want to touch checkTestRuntime as this change "ripples" through all the tests using it. And I also didn't want this bugfix PR to be 90% me refactoring test code.

This is a generic helper that I'm sure we're duplicating elsewhere, as this setup boilerplate is very commo

We are but in every case we need something additional for each module separately.

As part of the ESM saga I would like to be able to test the module loading and resolution in tc39 and also to be usable from other k6 modules (and extensions as consequence). As part of that I will likely try to refactor all of the helpers through k6 modules at least a little bit, hopefully most will be pretty straightforward 🤞

But that will be a huge PR or a bunch of pretty big ones as in most cases this helpers are used a lot and then their result(s) are used even more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#2946 for just how many line changes the refactor of just this, really small module, are.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Yeah, I imagined it wouldn't be a short diff, but still, it DRYs things up considerably.

@mstoykov mstoykov merged commit 0b1fe61 into master Mar 6, 2023
@mstoykov mstoykov deleted the fixCheckAtEndOfIteration branch March 6, 2023 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

check randomly returning true unexpectedly
4 participants