call vs callonce for Auth Setup Reuse in Karate DSL

Choosing Between call and callonce for Shared Authentication

When structuring a Karate test suite that requires an authenticated session across multiple scenarios, the decision between call and callonce for the login feature directly affects test isolation, execution time, and token validity.

Constraint: Token Expiry and Parallel Execution

The authentication token returned by the setup feature has a fixed TTL (e.g., 15 minutes). The suite runs in parallel across multiple threads or Maven forks. callonce caches the result for the test run, but its cache scope — per JVM, per thread, or per fork — is version-dependent and not globally guaranteed. call in a Background re-executes the login per scenario, preserving isolation but increasing API calls and risking rate limits.

Unresolved Decision

The team needs a single documented approach that works reliably across local runs, CI pipelines with forked test processes, and parallel threads without manual token refresh logic in every scenario.

• Does callonce cache scope extend across forked JVMs in the same Maven/Gradle build, or is it confined to a single runner instance?
• If the token expires mid-suite, which approach allows a transparent refresh without duplicating logic in each scenario?
• Are there documented patterns in the Karate version used that combine callonce with a conditional re-authentication hook?