-
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
Treat go panics as an interrupt error #2453
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! But can you try to make an "integration" test that will test that this will abort a whole test 🤔 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as well, but also agree with @mstoykov's desire for an integration test. With the recent cmd/
changes, it should be relatively easy to create an integration test that injects a mock JS extension that just calls panic()
and then start a test that imports it and calls it.
Actually, it will probably be even better to have 2 integration tests, one that panics in the init context and one that panics in the VU context.
163f011
to
3aeed9a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except that minor nitpick
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I have some nitpicks but we can do them later I guess
@@ -186,7 +186,7 @@ func TestVUTags(t *testing.T) { | |||
}) | |||
} | |||
|
|||
func TestAbortTest(t *testing.T) { //nolint: tparallel | |||
func TestAbortTest(t *testing.T) { //nolint:tparallel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I kind of prefer to not have unrelated changes in unrelated files like that ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like a personal preference 🤔 Let me try to provide my two cents on why I'm doing this and continue doing it.
It's a common/best practice to leave the place cleaner than before. For example, this is a comment for a machine (linter) comment, and it doesn't require space in between. The same things I usually do when spotting any grammar issues. Such changes itself is super-minor and don't deserve a separated PR, so that's why I prefer not postpone fixing.
Does that make sense? Will it help if I'll do this in a separate commit?
72e14c2
to
24d5940
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
What?
We change the behavior, and the go
panic
's will be treated as the run interruption.Why?
Otherwise, it is hard to detect panics in the code
Changelog
We changed the behavior of how the k6 treats the panic that can happen during the execution of the JavaScript code. Previously the behavior was to catch the panic and log it as an error. Starting the
v0.38.0
whenever k6 sees a panic, it logs an error like before, but more importantly, it will abort the script execution. This change should help identify and fix the issues earlier.Closes #2354