In Karate, when you write `* def result = call read('helper.feature') { id: 5 }`, what exactly does `result` hold?

## The result is a map of variables, not a report `* def result = call read('helper.feature') { id: 5 }` isolates the call, and what lands in `result` is a plain map whose keys are variable names. There is no status, no timing and no step list in it - execution results go to the report, and a failure inside the callee throws rather than being handed back as data. So the only question worth asking is *which* variables make it in. ## Which variables make it in Three rules decide the contents: - **Only the last executed scenario counts.** A called feature runs every scenario it contains, and the result map is built from the variables in scope at the end of the last one. If `helper.feature` has two scenarios, whatever the first one defined and the second one did not is not in the map. - **Only the callee's own contribution is included.** A called feature can read the caller's variables, so at the end of the run its full binding set echoes the caller's scope back. Karate strips that inherited scope out, leaving the variables the callee actually defined or replaced. Without this filter every call result would drag the caller's locals and config-level values along with it. - **The call argument's keys are the callee's own.** The keys of `{ id: 5 }` are set as ordinary variables inside the callee, and they are counted as its own bindings, so `result.id` is 5 even if `helper.feature` never mentions `id`. The hidden call bindings `__arg` and `__loop` are deliberately excluded - they exist for the callee to read and are never returned. ## Called features run all their scenarios This surprises people the first time a helper grows a second scenario. Tag filters that apply to a top-level run are not applied to a called feature, so a reusable file marked `@ignore` still runs every scenario when it is called. Two practical consequences: 1. A helper you intended as one routine now runs twice as much work per call. 2. The result map suddenly reflects the *second* scenario, and a variable the first one defined may be missing. Keeping a reusable feature to a single anonymous `Scenario:` avoids both, which is why upstream's own reusable features are written that way. ## An array argument changes the shape The argument is not just data - its type selects the call mode. | Argument | What runs | What `result` holds | |---|---|---| | omitted | the feature once | a map of the callee's variables | | a JSON object | the feature once, keys spread as variables | a map of the callee's variables | | a JSON array | the feature once per element | a **list** of those maps, in order | ```gherkin * def rows = [{ name: 'ann' }, { name: 'bob' }] * def results = call read('create-user.feature') rows * match results == '#[2]' * print results[1].userId ``` Writing `result.userId` against a list is the classic mistake here; the value you want is `result[0].userId`. ## Why the delta matters beyond tidiness The result map of an isolated call is also what a cached call replays and what a disk-backed cache serialises. If the map echoed the caller's whole scope, a cache entry would carry one caller's locals into every later caller, and log output would balloon. Treating the map as "what this feature produced" rather than "everything that was in scope" is what keeps a reusable feature genuinely reusable. ## Reading the result well - Unpack it immediately into named variables if the rest of the file reads better that way: `* def token = auth.token`. - Assert on it like any other JSON value - `* match result contains { id: 5 }` works, and is a cheap guard that the helper actually produced what you expect. - Do not assume a key exists because the helper defines it somewhere; check which scenario ran last. - If you find yourself unpacking six keys after every call, that helper probably wants shared scope instead, and the bare `call` form will save the unpacking. ## What is not in the map Three things people look for and never find: - **The hidden call bindings.** `__arg` and `__loop` are injected for the callee to read and are excluded from the result, so `result.__arg` is undefined. - **The caller's own variables.** They were readable inside the callee, but they are filtered out of the map precisely so a call result means "what this helper produced". - **A status.** A called feature that fails throws into the caller and fails the calling step; there is no success flag to inspect, so an assertion after the call is checking the helper's output, never whether it ran.