Examples Tables vs call read with Runtime Data in Karate Data-Driven Tests

When building data-driven API tests in Karate, the test matrix often depends on identifiers or tokens returned by a setup request executed during the run. The framework offers two documented paths: a Scenario Outline with an Examples: table, or a called feature invoked via call read() passing a table variable or JSON array constructed at runtime.

Examples: tables expand each row into a standalone scenario in the HTML report, making failures easy to trace, but cells can only reference variables already in scope through inline JavaScript expressions. In contrast, call read() with a runtime-built array composes naturally with callonce setup steps, allowing each row to incorporate values fetched moments earlier.

The trade-off centers on failure-reporting granularity: called features surface rows through the caller/callee hierarchy rather than as top-level outline rows, and the exact report layout and parallel worker distribution vary across runner APIs and Karate releases. Teams must decide whether the readability of precomputed Examples: rows outweighs the flexibility of generating test data on the fly.

How does your pinned Karate version render failures for called features versus expanded outline rows in the HTML report? Does the parallel scheduler distribute called-feature rows differently than Examples rows under your runner (JUnit 4, JUnit 5, or CLI)?