aglinxinyuan opened a new issue, #7553: URL: https://github.com/apache/texera/issues/7553
### Task Summary `amber/src/main/scala/org/apache/texera/web/resource/SyncExecutionResource.scala` is the **largest uncovered file in the repository**: 406 instrumented lines, **0% covered**, and no spec anywhere (a whole-repo search finds only the class, two registration sites in `ComputingUnitMaster`, and three passing mentions in comments). That matters more than the raw number suggests. This is the endpoint an external caller uses to run a workflow and get results back in a single request, so its result assembly, its error classification and its cell-truncation rules are all directly user-visible. None of the reachable part needs infrastructure, and the seam is better than it looks: - `class SyncExecutionResource extends LazyLogging` is **zero-arg** with no injected collaborators. `new SyncExecutionResource()` works in a plain `AnyFlatSpec` with no fixture. - `WorkflowExecutionService` is directly constructible with `coordinatorConfig = null` and `resultService = null` — `WorkflowExecutionServiceSpec` already does this — and its `client` is a null `var`, which is exactly what the kill/shutdown null-guards want. - `WorkflowService.getOrCreate(...)` succeeds engine-free. - `SqlServer.getInstance()` is satisfied by MockTexeraDB, which amber already has via `DAO % "test->test"`. **The key unlock for the public endpoint**: `executeWorkflowSync` reaches `WorkflowService.initExecutionService`, which fails on `workflow_executions_cuid_fkey` unless a `workflow_computing_unit` row exists. Insert that one row and init *completes* with no engine — it wraps the `new WorkflowExecutionService(...)` / `executeWorkflow()` pair in `try/catch(Throwable)`, so the engine failure is absorbed into the metadata store as FAILED and the method returns normally. `executeWorkflowSync` then takes the `isTerminalState` fast path and runs the whole result-assembly tail. Measured, not estimated: a probe reached 186/406 with **no** infrastructure at all and 206/406 adding MockTexeraDB. Two structural notes for whoever picks this up: 1. **14 of the 16 methods are `private def`**, so most helpers are only reachable through ScalaTest's `PrivateMethodTester` (there is repo precedent — eight existing specs use it). Widening the nine pure helpers to `private[resource]` would remove nearly all of that reflection for a one-word change each, and is worth considering separately. 2. **~139 lines are behind real Iceberg result storage** (`collectOperatorResult`, the symmetric-truncation engine). `DocumentFactory.openDocument` is an un-displaceable static for `vfs://` URIs. `common/workflow-core`'s `LocalHadoopIcebergCatalog` test helper would unlock it, but amber's project declares only `DAO % "test->test", Auth % "test->test"` (build.sbt:270), so that helper is not on amber's test classpath. Adding `WorkflowCore % "test->test"` would take this file to roughly 87%. Also worth recording: measuring this file needs the `jacoco` task with a `Test/testOptions` filter. `WorkflowExecutionService/Jacoco/testOnly` does not parse — sbt-jacoco 3.5.0 defines only the `jacoco` task — and a bare `jacoco` runs the whole amber suite including `@IntegrationTest` specs, which hang on Windows. ### Task Type - [ ] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [x] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
