In Karate, what does `* configure afterScenario = function(){ ... }` do, and why does the same line have no effect inside a feature that is invoked with `call`?

## A hook here is a value, not a declaration In a step-definition framework a hook is something you declare — an annotated method that a registry discovers. Karate has no step-definition layer to hang that on, so a hook is simply a JavaScript function assigned to a configure key: ```gherkin * configure afterScenario = function(){ karate.log('done:', karate.scenario.name) } ``` The three after-hook keys work the same way: | key | fires | |---|---| | `afterScenario` | after each scenario, including each `Examples` row of an outline | | `afterScenarioOutline` | once after the whole outline has run its rows | | `afterFeature` | after the feature's scenarios have finished | Because the value is an ordinary function, it can be read from a shared `.js` file, and it can hand control to a whole feature with `karate.call('after-scenario.feature')` when the teardown is more than a line. ## It runs on the failing path too The hook is invoked from the scenario's cleanup path, which runs regardless of how the scenario ended. A scenario that failed on a `match` still gets its `afterScenario`, which is what makes the key usable for teardown — deleting a record the scenario created, releasing a fixture, logging a correlation id for the failure. A dry run skips it. ## Why a called feature's hook does nothing This is the part people hit in practice. Before invoking the hook Karate checks whether the current scenario has a caller and returns immediately if it does; the source comments the check as *do not call hooks on called scenarios/features*. All three after-hook keys are gated the same way. The reason is recursion: a hook is allowed to use `karate.call`, and a hook that fired inside called features would re-enter itself for every level of nesting. The consequence for design is concrete: 1. Putting `configure afterScenario` in a shared helper feature does nothing when that helper is called — and quietly starts working if someone ever runs the helper directly. 2. Teardown that must always happen belongs in the top-level feature, or in the config file so every top-level scenario picks it up. 3. If a called feature genuinely needs cleanup, do it with ordinary steps at the end of the called feature, not with a hook. Karate's own demo suite pins this: a called feature carries the line together with the comment that it is not supported when the feature is called, and the calling feature has a scenario named for the same point. ## What happens when the hook itself throws This is the one place where the two Karate lines genuinely differ, so it is worth stating with versions. On **1.5.2** an exception inside the hook is caught, logged at WARN as `afterScenario hook failed: ...`, and swallowed — the scenario still reports as passed. On **2.x** the hook is recorded as a step of its own and a throw **fails the scenario**, the same convention a failing step follows; you opt out by wrapping the hook body in a `try`/`catch`. The practical reading is the same on both: a teardown hook that can fail should say so itself. Do not rely on the runtime to surface it, and do not rely on it staying quiet either. ## Reviewing a hook-based teardown - Is the hook installed where it will actually fire — top-level feature or config file, not a called helper? - Does the body assume the scenario passed? It also runs after failures, where variables may be unset. - Does it call out to an external system? A slow hook multiplies across every scenario in the suite. - Is a failure inside it visible to whoever reads the report, rather than only to whoever reads the log? - Would ordinary steps be clearer? A hook is invisible at the point of failure, and that cost is real for anyone reading the feature file cold. ## The short version "A Karate hook is a JavaScript function assigned to a configure key. `afterScenario` runs after every scenario in scope, whether it passed or failed, but only for top-level scenarios — the runtime skips it whenever the scenario has a caller, so the line does nothing in a called feature."