Mock Server latency simulation inconsistent in parallel execution

Goal

We want to validate client‑side logic against a Karate mock server without using production credentials, while also emulating realistic network delays and error conditions.

Constraints

The mock server does not automatically inject latency or TCP failures; it only returns predefined responses. When tests run in parallel, global variables modified by the configure keyword can bleed across threads, potentially masking latency effects.

Unresolved Questions

1. What configuration or scripting technique allows the mock server to inject per‑request latency that can be reliably measured by the test suite?
2. Which best practices or Karate features guarantee isolation of global state when the mock server is exercised in parallel scenarios?
3. Is there a built‑in assertion method to verify that the simulated latency was applied during a test run?