karate.callSingle() result caching and resource cleanup

Shared State Management in Karate

The karate.callSingle() feature is used to execute a setup feature once per test run and reuse the resulting value across multiple features and parallel threads. By default, these results are retained for the duration of the run to optimize performance.

While configure callSingleCache allows for the definition of a time-to-live (TTL) or the complete disabling of the cache, there is an architectural decision regarding the lifecycle of the resources created by these calls. Karate provides both afterScenario and afterFeature hooks for teardown operations.

When using a shared setup that persists across the entire execution, it is unclear which hook is the appropriate location for releasing those shared resources without prematurely terminating the state for other concurrent threads in a parallel runner environment.

• How does the callSingleCache TTL interact with the execution of afterFeature hooks in a parallel run?
• Which hook is recommended for cleaning up resources initialized via callSingle() to ensure they are released only after all dependent features have completed?