How do k6's exec.test.abort() and exec.test.fail() differ in effect and in exit code?

## Two ways for a k6 script to declare its own failure Thresholds let k6 decide the verdict from measurements. The `k6/execution` module gives a script two ways to decide it directly, and they behave very differently: - **`exec.test.abort([msg])`** — stops the entire test run **immediately** and exits **108**. - **`exec.test.fail([msg])`** — marks the run failed but **lets it finish**, then exits **110**. Both take an optional string message. Both are reached through the `test` object on the default export of `k6/execution`, and k6 documents them qualified that way — `exec.test.abort()`, never a bare `test.abort()` with the object left unnamed. ## abort(): an interrupt `abort()` raises an interrupt inside the JavaScript runtime. In Go terms it constructs an `errext.InterruptError`, whose `ExitCode()` method returns `exitcodes.ScriptAborted` — 108 — and whose abort reason is `AbortedByScriptAbort`. The interrupt unwinds the current iteration, and the scheduler brings the whole run down; no further iterations start in any VU. Two details are worth memorising: 1. **`teardown()` still runs.** k6's own test fixture aborts from the default function and asserts that the teardown log line appears. Aborting is not a hard kill. 2. **The message is prefixed.** `exec.test.abort('oops!')` surfaces as `test aborted: oops!`, with the source position appended, in both the log and the run's exit event. An abort from the script's **init context** — module top level, before any VU runs — also exits 108, but the run never reaches the end-of-test stage at all. ## fail(): a flag, not an interrupt `fail()` does not throw and does not interrupt anything. It does exactly three things: it composes the reason `test marked as failed` (plus your message, if given), logs it at error level, and calls `MarkFailed()` on the run's status. Then your iteration continues from the next statement, and every other iteration in the run proceeds normally. The exit code arrives much later. After the scheduler returns, `internal/cmd/run.go` checks `testRunState.TestStatus.Failed()` and, if it is set, returns an error carrying `exitcodes.MarkedAsFailed` — 110. Calling `fail()` a hundred times is the same as calling it once; the status is a boolean, not a counter. One constraint: `fail()` needs a VU. Called where there is no VU state — the init context — it throws `execution.test.fail() called outside of VU context` instead of marking anything. ## Side by side | | `exec.test.abort()` | `exec.test.fail()` | |---|---|---| | exit code | 108 | 110 | | stops the current iteration | yes, immediately | no | | stops the rest of the run | yes | no — all iterations finish | | `teardown()` runs | yes | yes | | effect of calling it twice | the first one already ended the run | identical; the status is a flag | | legal in the init context | yes | no — it throws instead | | remaining measurements | lost, the run is cut short | complete, the run ran in full | ## Choosing between them The distinction that matters for a build step reading the code is **whether the rest of the run's data is trustworthy**. After 108, the run is a fragment: it stopped at an arbitrary moment, so its totals and its per-metric statistics describe less load than you configured. After 110, the run is complete — the same duration, the same iterations, the same summary you would have got had nothing failed — with one bit flipped to say "this result is a failure". A job that wants to keep the artefacts and compare them against a previous run can do that after 110 and cannot honestly do it after 108. That makes the practical rule easy to state: abort when continuing would be pointless or actively harmful — the environment is wrong, a dependency is unreachable, every request is failing — and fail when the run should complete so its numbers stay comparable, but its verdict is already decided. There is a reporting difference too. `fail()` logs its reason at error level on **every** call, so the log records each occurrence even though the status is a single boolean and the exit code is set once. `abort()` records exactly one reason, prefixed with `test aborted:` and carrying the source position, because there is only ever one abort per run. ## In k6 v2 Both functions are on the stable `k6/execution` module in k6 v2.x, and both exit codes are fixed constants in `errext/exitcodes/codes.go`. Neither has anything to do with thresholds: they set the code directly, without evaluating any metric.