Two scenarios in one Karate feature each need a different login, and both go through `* def token = callonce read('login.feature') creds` where `creds` is set per scenario. Both end up with the first scenario's token — why, and how do you fix it?

## The mechanism behind the surprise When Karate executes a `callonce` step it takes the text after the keyword — the whole call expression, `read('login.feature') creds` here — and uses that string as the cache key. It looks the string up first, and only on a miss does it evaluate the expression, run the callee and store the result under that same string. Nothing about the *value* of `creds` participates. The lookup happens before the argument is evaluated, so two scenarios that differ only in what they bound to `creds` are, to the cache, the same call. The evidence that this is textual rather than semantic is visible in how carefully the key is assembled: when the argument is supplied as a doc-string under the step, that doc-string is appended to the key precisely so that two steps differing only in their doc-string cache separately. ## Why it reads as correct code The step looks parameterised. A reader sees a variable being passed and assumes the cache is keyed on the call *and* its input, the way a memoized function would be. It is not — it is keyed on the source line. The failure is silent: the second scenario gets a perfectly well-formed token belonging to the wrong user, and the assertion that eventually fails is somewhere downstream, usually a 403 or a payload holding another account's records. The same shape catches people with a `Scenario Outline`. Every `Examples` row re-runs the `Background`, and every row's step has identical text, so a `callonce` there is one execution for the whole table — which is exactly what you want when the setup is shared, and exactly wrong when the row is supposed to drive it. ## Three fixes, in the order you should consider them 1. **Do not cache it.** If each scenario genuinely needs its own sign-in, the setup is not shared and `call` is the correct keyword. Caching something that varies per scenario is the actual mistake; the key is only how it surfaces. 2. **Make the expressions different text.** Inline the differing argument as a literal so the two steps no longer match: ```gherkin * def adminToken = callonce read('login.feature') { user: 'admin' } * def userToken = callonce read('login.feature') { user: 'guest' } ``` Two distinct keys, two executions, each cached for the rest of the feature. This works because the key is the text, and it fails the moment someone refactors the literals back into a variable. 3. **Use the cache built for two variants of one file.** `karate.callSingle()` keys on the path string, and Karate provides a `?name` suffix specifically to split that key. The suffix is stripped before the file is read, so both calls run the same feature: ```javascript var admin = karate.callSingle('classpath:login.feature?admin', { user: 'admin' }); var guest = karate.callSingle('classpath:login.feature?guest', { user: 'guest' }); ``` This also widens the cache from the feature to the whole run, which is usually what you wanted for a login anyway. ## Reviewing for it The rule that catches this in review is short: **the argument to a `callonce` should be a constant of the feature, not of the scenario.** Concretely, treat these as suspicious: - a `callonce` whose argument is a variable that any scenario or `Examples` row assigns; - a `callonce` inside a `Scenario Outline`'s `Background` that references a placeholder-derived value; - two `callonce` steps in one file whose text matches but whose intent differs. ## Two related boundaries worth knowing The cache lives on the running feature, so this collision is confined to one file — a second feature file with the same step text has its own entry and signs in again. And a feature that is itself being *called* gets a fresh cache per invocation, so a `callonce` inside a called feature invoked once per outline row does re-execute per row rather than freezing on the first caller's scope. That asymmetry surprises people in the other direction: they expect a `callonce` in a called feature to de-duplicate across invocations, and it does not. Finally, note what does **not** rescue you here. A cache hit hands back a copy, so mutating the returned token in the second scenario does not fix anything — it was the wrong token before you touched it. And a failed call is not cached at all, so a login that throws will be retried; only a *successful* wrong-user login is sticky.