-
Notifications
You must be signed in to change notification settings - Fork 216
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
Option 'throw' is broken or badly documented #251
Comments
It depends on how you defined failed request. You can load test an endpoint which return 404 or 400. If you expect it to return 400, but it return 200, then it's a failed request in scope of your test. |
In the end I assumed that that is indeed what the documentation meant. Apart from the documentation I also think that the feature would make much more sense when it also applied to 4xx and 5xx errors:
|
@markjmeier I looked at the source code again, and the term of failed request is not about 4xx and 5xx status code, but
|
Thanks for mentioning this, we'll improve the docs for But the use case of throwing errors when the connection can't be established (or there's a DNS error, TLS error, etc. non-application errors) or when the remote server returns a response with a 4xx/5xx (application error) status is a very valid use case. Unfortunately, the current global |
@na-- should this really be here? I get the impression that you wanted to have this as some kind of input to the design of the new HTTP API? |
A bit of both. We should better document how the current Or that, until recently, if you had mistyped your URL, k6 would have thrown an error, even if And yes, we'll probably rethink if we'll even have a In summary: this issue should be here, and it probably deserves at least a normal priority, since it's a common footgun. |
Appreciated, thanks! |
It has been three years since the creation of this issue. Now, k6chaijs tries to solve this problem by throwing an assertion on failures. I am closing this issue. I suggest following the discussion on the k6 repo or https://github.com/grafana/k6-jslib-k6chaijs/ |
Expected behaviour
Enabling throw exits the specific test iteration as soon as an request error occurs: connection issues, status 4xx, status 5xxx.
I hoped that with this option I wouldn't have to write
check
s for every request.Actual behaviour
Status errors don't exit the iteration, or show anything in the log.
Documented behaviour
A boolean, true or false, specifying whether to throw errors on failed HTTP requests or not.
The text was updated successfully, but these errors were encountered: