In a Karate feature file `cat.kittens` holds two objects with ids 23 and 42. Why does `* match cat.kittens[*].id == 23` fail, and how do you assert on just the first id?

## Indefinite paths return lists JsonPath distinguishes a **definite** path, which can only address one node, from an **indefinite** path, which addresses a set. Three things make a path indefinite: - a wildcard — `cat.kittens[*].id` - a recursive descent — `response..username` - a filter — `cat.kittens[?(@.id == 23)]` An indefinite path always evaluates to a **list**, regardless of how many nodes it happened to hit. One match gives you a one-element list, not the element. This is the single most common surprise for someone new to Karate's `match`, because the step reads like a field access: ```gherkin * def cat = { name: 'Billie', kittens: [{ id: 23, name: 'Bob' }, { id: 42, name: 'Wild' }] } # FAILS - the left side is [23, 42], the right side is a number * match cat.kittens[*].id == 23 # passes - compare the selection to the selection you expected * match cat.kittens[*].id == [23, 42] ``` Karate's `match` is a deep, order-sensitive structural comparison, so `[23, 42]` and `23` are not comparable values and the step fails with a type mismatch rather than quietly coercing. ## Three ways to say what you meant 1. **Assert the whole selection.** `match cat.kittens[*].id == [23, 42]` is usually the strongest assertion, because it pins the count as well as the values. Prefer it when the payload is small and stable. 2. **Assert membership.** `match cat.kittens[*].id contains 23` says "23 is among the ids" without caring about the rest. Useful when the array grows over time. 3. **Collapse the list to one element.** This is what the index form of `get` is for. ## `get[N]` collapses a list The `get` prefix evaluates a JsonPath against a named variable, and `get[N]` additionally returns element *N* of a list-shaped result: ```gherkin * def actual = 23 # instead of two steps * def kitnums = get cat.kittens[*].id * match actual == kitnums[0] # one step * match actual == get[0] cat.kittens[*].id ``` Note which side `get[0]` is on. It prefixes an *expression*, so Karate 1.x resolves it after `def ... =` and on the **right** of a `match` — never at the head of the left side, where `get[0] cat.kittens[*].id` is split into the variable `get` plus the path `$[0] cat.kittens[*].id` and the step fails with `ReferenceError: get is not defined`. It earns its keep with **filters**, where the array is an artefact of the query and you only ever wanted one row: ```gherkin * def bob = get[0] cat.kittens[?(@.id == 23)] * match bob.name == 'Bob' ``` Without the `[0]`, `bob` would be a one-element array and `bob.name` would be undefined. ## What indexes and what does not | Form | Applies a JsonPath | Takes an index | |---|---|---| | `get cat.kittens[*].id` | yes | no | | `get[0] cat.kittens[*].id` | yes | yes | | `$cat.kittens[*].id` | yes | **no** | | `cat.kittens[*].id` on the left of `match` | yes | no | | `get[0] cat.kittens[*].id` on the left of `match` | no — the step errors | no | The `$variable` short-cut is otherwise interchangeable with `get`, but the index is a convenience of the `get` spelling only. If you are reaching for `$` and an index, use `get[N]` instead. Also worth separating in your head: `cat.kittens[0].id` and `get[0] cat.kittens[*].id` are **not** the same expression. The first indexes the `kittens` array *inside* the path and stays definite, so it evaluates straight to `23`. The second runs a wildcard query and then takes the first element of the result set. They agree here, and they stop agreeing the moment the path is a filter or a recursive descent, where there is no positional index to write inside the path. ## The failure this prevents The reason interviewers ask is that the wrong mental model produces assertions that look right and are weak. Someone who believes a wildcard yields a scalar writes `match response.items[*].status == 'ACTIVE'`, watches it fail, and "fixes" it by switching to `contains`. That now passes if *any* item is active, which is a much weaker check than they think they wrote — and it keeps passing when a second, inactive item appears. Knowing that the left side is a list makes you choose deliberately between the whole-array comparison and membership. ## Reading a failure message When the shapes disagree, Karate reports a data-type mismatch and prints both sides, which is usually enough to spot the problem on the first run — the actual side arrives in brackets and the expected side does not. Train yourself to read that bracket as the signal it is: it means the path you wrote was a query. From there the decision is not "how do I make this pass" but "did I want one value or a set", and the answer determines which of the three fixes is honest. A wildcard you did not intend usually means the path should have been definite in the first place — `response.items[0].id` rather than `response.items[*].id` — and tightening the path beats loosening the assertion every time.