A reusable Karate feature picks up the right `baseUrl` when run on its own, but the wrong one when the same file is reached through `call read('setup.feature')` from another suite. What is the mechanism?

## The rule Karate evaluates its config chain for **top-level scenarios only**. A scenario reached through `call`, `callonce` or the JavaScript call API has a caller, and for it the chain — `karate-base.js`, then `karate-config.js`, then `karate-config-<env>.js` — is skipped entirely. Not deferred, not cached: skipped. This is a single condition inside the engine, and both the file-reading and the evaluation sit behind it. It is not affected by how deep the call is, whether the callee is in another directory, or whether it happens to have its own `karate-config.js` nearby. ## What the called feature gets instead Skipping the chain does not leave the callee empty. Karate builds a fresh context for the called feature and seeds it from the caller: - **Every variable the caller holds** at the moment of the call — which includes everything the caller's own config chain produced. - **The caller's `configure` settings**, so timeouts, headers and SSL behaviour carry across. - **The call argument**, if one was passed, whose keys are applied on top and therefore win over the inherited names. So a called feature can freely write `Given url baseUrl`. That name is there — it just arrived through the caller rather than through a config evaluation of its own. ## Why standalone and called runs differ Once you know the chain is caller-scoped, the reported symptom explains itself: | Run shape | Config chain | `baseUrl` comes from | |---|---|---| | `setup.feature` run directly | evaluated for it | that run's own config, with that run's `karate.env` | | `setup.feature` reached by `call` | skipped | the caller's variables, from the caller's config evaluation | The two agree whenever the caller and the standalone run share a config and an environment. They diverge as soon as either differs — the caller was launched without `karate.env`, or the caller belongs to a different module with its own `karate-config.js`, or the caller redefined `baseUrl` with a `def` before making the call. ## Consequences worth knowing 1. **You cannot switch environment mid-suite by calling a feature.** Calling a feature that lives beside a `karate-config-prod.js` does not load it. The only lever is the run's own `karate.env`. 2. **A green standalone run of a reusable feature proves less than it looks.** It exercised the feature against *its own* config. The same file inside a caller runs against the caller's. 3. **Work you put in `karate-config.js` happens once per top-level scenario, not once per call.** A suite whose scenarios each call three features still evaluates the chain once for each of those scenarios, and zero extra times for the calls. 4. **The callee cannot rely on a variable the caller never had.** If a reusable feature needs `tokenUrl`, then every caller's config must define it, or the caller must pass it as the call argument. That is the contract, and it is worth writing down at the top of the reusable file. 5. **Environment tags behave the same way.** Scenario selection tags that depend on the environment are applied at top-level selection; a called feature runs its scenarios regardless. The same top-level-only principle governs both. ## How to diagnose it When a called feature behaves unexpectedly, the fastest confirmation is to print the value at both ends: ```gherkin # in the caller, immediately before the call * print 'caller baseUrl:', baseUrl * call read('classpath:setup.feature') ``` ```gherkin # first step of setup.feature * print 'callee baseUrl:', baseUrl ``` If the two agree, the config chain is behaving exactly as designed and your problem is in the caller's config. If the callee's is undefined, the caller never had it — which means either the caller's config does not define it or you expected the callee's own config to supply it. ## Designing around it The robust pattern is to treat a reusable feature as a function with an explicit signature. Pass what it needs as the call argument rather than relying on inherited names: ```gherkin * def result = call read('classpath:signin.feature') { baseUrl: '#(baseUrl)', user: 'admin' } ``` Call-argument keys are applied on top of the inherited variables, so they are unambiguous, they document the dependency at the call site, and they survive a caller whose config happens to name things differently. Relying on inherited config names is convenient and legitimate for a small suite; it becomes a hidden coupling once several projects call the same feature.