When a Gatling check fails, what does the default error message contain, and how do name(...) and logActualValueInError(false) change it?

Gatling reports a failed check as an error message on the KO request, and those messages are what the HTML report's error table groups by. Knowing exactly how the message is assembled is what lets you keep that table readable on a run with tens of thousands of virtual users. ## How the message is assembled Gatling composes a check's display name as: ``` customName OR extractorName + "." + arity + "." + validatorName ``` and then reports the failure as that name, a comma, and the validator's own outcome string. * **`extractorName`** is the check type with its criterion, for example `jsonPath($.orderId)` or `regex(order (\d+))`. * **`arity`** is the extraction step you chose. It renders as `find`, `find(2)`, `findAll`, `count`, `findRandom` or `findRandom(3, true)`. Note that `find(0)` renders as plain `find`, so an explicit first-occurrence extraction is indistinguishable from an omitted one. * **`validatorName`** is the validation step: `exists`, `notExists`, `optional`, `is(201)`, `in(200,201)`, and the spelled-out `greaterThan(0)`, `greaterThanOrEqual(1)`, `lessThan(500)` and `lessThanOrEqual(500)` that `gt`, `gte`, `lt` and `lte` render as. The result is that **the error message spells out the steps you did not write**. A check written as nothing more than `jsonPath("$.orderId")` fails with `jsonPath($.orderId).find.exists, found nothing`, naming both the implicit `find()` and the implicit `exists()`. ## The outcome string comes from the validator There is no single two-case rule: the tail is whatever the validator you wrote returns. | validator | nothing was captured | the failing case, with logging on | |---|---|---| | `exists` (the implicit one) | `found nothing` | it has no other way to fail | | `is`, `isNull`, `in` | `found nothing` | `found <actual value>` | | `lt`, `lte`, `gt`, `gte` | `can't compare nothing and <expected>` | `<actual> is not greater than <expected>`, and the matching wording for the other three | | `notNull` | `found nothing` | `failed` — it never interpolates the value | | `notExists`, `not(x)` | no failure at all | `unexpectedly found <actual value>` | | `optional` | no failure at all | it never fails | Turning the flag off with `logActualValueInError(false)` collapses `is`, `isNull`, `in`, `notExists` and the four ordering validators to a flat `failed`. `exists`, `optional` and `notNull` are unchanged, because none of them reads the flag; `not(x)` emits `unexpectedly found <actual value>` whether the flag is on or off. Failures earlier in the chain get their own shapes — `... extraction crashed: <message>` and `... preparation crashed: <message>` — which is how you tell a malformed response apart from an honest mismatch. ## `name(...)`: replace the prefix `name(name)` takes a **static String only** and replaces the whole generated prefix. It is an optional step in its own right, sitting between validation and saving in Gatling's six-step chain. Two things it buys you: 1. A message that reads as a business fact rather than as a selector: `order id present in create-order response` instead of `jsonPath($.orderId).find.exists`. 2. Stability. Change the JSONPath expression and the generated name changes with it, splitting a previously single error row in two across runs. A declared name does not move. ## `logActualValueInError(false)`: cap the cardinality Added in **Gatling 3.15** under the heading *Controlling error messages cardinality*, this step turns off interpolating the actual value into the message. Gatling's own wording marks the boundary precisely: *most checks that apply a condition on an expected value* log the actual value when they fail. That is the whole scope — the flag reaches `is`, `isNull`, `in`, `notExists` and `lt`/`lte`/`gt`/`gte`, and no other validator reads it. Consider `jsonPath("$.id").isEL("#{orderId}")` on a follow-up request, where the expected value is per-user. With logging on, 50,000 users produce up to 50,000 distinct error strings, and the report's error table becomes one row per user. With `logActualValueInError(false)` they collapse into a single row reading `failed`. It does **not** affect `found nothing` — a value that was never captured has nothing to log — nor the ordering validators' absent branch, which reports `can't compare nothing and <expected>` either way. And it does nothing at all on a pure capture such as `jsonPath("$.orderId").saveAs("orderId")`: that check's validator is the implicit `exists()`, which ignores the flag entirely, so it is already one error row for the whole run; `name(...)` is what improves it. ## Using them together The two steps are complementary and both are cheap: * Use `name(...)` on any check whose generated name would be a long or volatile selector. * Use `logActualValueInError(false)` on any check that **compares** against an expected value where the actual varies per user — identifiers, tokens, timestamps, session values. On a capture-only check it is inert. * Keep logging **on** for low-cardinality checks such as `status().is(200)`, where `found 503` is exactly the diagnosis you want and there are only a handful of distinct values it can take. ## One subtlety about which failure you see Gatling runs **every** check on a response even after one of them fails, but reports only the **first** failure. For HTTP it also sorts checks by scope before running them — URL, then status, then header, then body, then time — regardless of the order you wrote them. So when a server returns a 500 with a JSON error payload, the reported message is the status failure, not the body failure, even if the body check appears first in your source. The body check still fails; you just do not see its message. Checks that **passed** still apply their `saveAs`, so a KO request can legitimately have written Session attributes.