Previously, k6 runners used to communicate errors by returning a non-200 status code, and not returning the logs of the execution. mq proxy, in addition to returning non-200 status codes, also includes an error code and description for errors that occur while running the script.
With the introduction of https://github.com/grafana/sm-k6-runner/pull/153, we now report as errors exceptions being thrown on the script, such as trying to access undefined variables, or invocations of fail(). In this scenario, users likely expect to see the check reported as a failure, but also to see the logs and metrics produced by it.
This PR changes the error-handling logic, so that the response is always parsed for status code that (should) include it, and the success of the check is calculated by checking if there response contains an error.
Previously, k6 runners used to communicate errors by returning a non-200 status code, and not returning the logs of the execution. mq proxy, in addition to returning non-200 status codes, also includes an error code and description for errors that occur while running the script.
With the introduction of https://github.com/grafana/sm-k6-runner/pull/153, we now report as errors exceptions being thrown on the script, such as trying to access undefined variables, or invocations of
fail(). In this scenario, users likely expect to see the check reported as a failure, but also to see the logs and metrics produced by it.This PR changes the error-handling logic, so that the response is always parsed for status code that (should) include it, and the success of the check is calculated by checking if there response contains an error.