Karate-config.js silent fallback when karate.env is missing

Karate-config.js environment bootstrap

When a test suite is executed in a container or CI pipeline, the karate.env system property is often omitted. Karate’s karate-config.js script then falls back to the default branch defined in the file, typically pointing at a local or dev endpoint. The suite passes, but it is actually running against the wrong host.

Locally the property is usually supplied via an IDE run configuration or a Maven/Gradle system property, so the intended environment is selected. In production or CI environments, the absence of karate.env can silently mask the mis‑configuration, leading to false positives in integration tests.

The core uncertainty is whether karate-config.js should throw an exception when karate.env is missing (fail‑fast) or continue with a permissive default. Karate does not enforce either policy, leaving the decision to the team.

What are the trade‑offs of implementing a fail‑fast guard for missing karate.env in karate-config.js? How can such a guard be coded without breaking existing local workflows? What fallback strategy would best balance safety in CI with flexibility for developers?