In Gatling's assertion DSL, what do `global`, `forAll` and `details(...)` each compute over, and how do you address a request that runs inside a group?

## Three scopes, and only three The first link of every Gatling assertion chooses **which requests** the statistic is computed from. There are exactly three entry points, and no others: | scope | what it computes over | |---|---| | `global` | every request in the run, aggregated into one set of statistics | | `forAll` | each individual request type in turn; the rule must hold for every one of them | | `details(path)` | one named request, or one group, addressed by its path | `global` and `forAll` are the two ends of a spectrum. `global` pools every request, so a rule written on it is a statement about the run as a whole. `forAll` expands into one evaluation per named request type, so the same rule now has to survive being applied to each request separately — including the ones you barely thought about. ## `details(path)` is a full-path match, not a search `details` is where most of the surprises live. The path is described as a Unix-like filesystem path, and it behaves like one in the strictest sense: **the parts you supply must equal the request's complete path**, group prefixes included. That means a request declared inside a group is *not* reachable by its own name alone: ```java // scenario: group("Purchase").on(exec(http("Checkout").get("/checkout"))) details("Checkout") // does NOT resolve - the real path is Purchase/Checkout details("Purchase", "Checkout") // resolves ``` Gatling's own test suite pins this: an assertion whose path parts do not match a recorded request path is reported as unresolvable, and an unresolvable assertion **fails**. That is the safe default, and it is the single most useful thing to know about this scope. A typo in a request name, a request renamed in the scenario but not in the assertion, or a request that never actually executed does not produce a green run with a quietly skipped rule — it produces a red run. ## Spelling the path, by language The path is assembled differently depending on which SDK you are writing: 1. **Scala** composes the parts with a `/` operator on strings: `details("Purchase" / "Checkout")`. 2. **Java, Kotlin and the JavaScript/TypeScript SDK** pass the parts as separate arguments: `details("Purchase", "Checkout")`. Both build the same list of path parts. Writing the Scala form in Java is a compile error, and writing `details("Purchase/Checkout")` in either is worse than a compile error — it is a single path part containing a slash, which will never match anything and will therefore fail at the end of the run. ## When the path names a group A path may address a group rather than a request. Two things then change, and both matter: - A response-time assertion on a group is matched against the group's **cumulated response time** — the time inside the group when requests were actually in flight, which is the group's elapsed duration minus the pauses. It is *not* the wall-clock time a virtual user spent between entering and leaving the group. - Count statistics on a group count **group executions**, not the requests underneath it. A group holding five requests and entered ten times has `allRequests().count()` of 10, not 50, and `details("Purchase").failedRequests().percent()` is the share of `Purchase` runs recorded KO — a group execution is KO when something inside it failed — rather than the failure rate of the requests in the flow. ## Message-driven protocols name the check, not the request For WebSockets, the name in `details(...)` is the name of the **check**, not the name of the request — the string you passed to `ws.checkTextMessage("...")` or `ws.checkBinaryMessage("...")`. Server-sent events behave the same way: `sse.checkMessage("...")` carries a name, and the SSE state machine logs that check name as the recorded action name on both success and failure, which is exactly what a `details(...)` path is matched against. Gatling's reference calls out only the WebSocket case, so SSE is the one that catches people twice over. Either way these are the places where the path is not built from request names, and they are easy to miss because everything else about the chain looks identical. ## Choosing between them, briefly Each scope buys a different failure mode, purely as a matter of what the grammar computes: - `global` gives one rule and one verdict, and it aggregates across request types, so it will not tell you *which* request moved. - `forAll` gives coverage with no maintenance, but it binds every named request, including a warm-up call or a health probe you never meant to hold to the same budget. - `details(...)` is precise and deliberate, and it is the only one that carries a maintenance cost: rename the request in the scenario and the assertion stops resolving, which shows up as a failed run rather than a skipped rule.