karate.callSingle Caching in Parallel Runs: Shared State and the JUnit 4 to JUnit 5 Boundary

Karate's callSingle feature is intended to execute a feature once and cache its result for the duration of a test run, so parallel scenarios can share setup data such as tokens or seed records. The cache is scoped to the Karate runtime or JVM, not to an individual feature file. The JUnit 4 to JUnit 5 runner transition in Karate 1.x is a compatibility boundary that changes how IDEs and build tools discover tests.

The unresolved design decision is whether the object returned by callSingle should be treated as immutable shared state or defensively copied per scenario. Because parallel scenarios receive the same cached reference, a mutation in one scenario can affect another, producing order-dependent behavior. Mixing JUnit 4 and JUnit 5 runner styles may also affect test discovery in some build setups.

Version-specific behavior for cache scope and report aggregation should be confirmed against the Karate version on the classpath.

Questions:

• Does callSingle return a shared mutable reference in Karate 1.x, and is that contract documented?
• Should shared setup data be deep-copied before each scenario consumes it, or is mutation an accepted pattern?
• How does the JUnit 5 @Karate.Test annotation interact with parallel execution and aggregated HTML reports compared with the JUnit 4 runner?