aglinxinyuan opened a new pull request, #7604: URL: https://github.com/apache/texera/pull/7604
### What changes were proposed in this PR? `collectOperatorResult` decides what an external caller actually receives from a synchronous run — how many rows come back, **which rows are dropped** when a result exceeds the character budget, and how individual cells are shortened. Roughly 180 lines, none of it covered. The spec's own scaladoc claimed the region was unreachable. It is not: `ExecutionResultServiceSpec` has been creating real Iceberg-backed documents in amber's test scope for some time via `DocumentFactory` against the ambient postgres catalog. The same pattern reaches this engine with **no build change and no new dependency**. That paragraph is rewritten in this PR to say what is true. Adds 10 tests to the existing spec: | | Before | After | |---|---|---| | Lines | 230/406 (56.7%) | **340/406 (83.7%)** | | Branches | 109 | 143 | The +110 lines are the whole of 523–708, including both catch arms. Covered: the empty-result short circuit, the visualization single-tuple path and its `__is_visualization__` flag, a first row that alone fills the budget, the sliding window that drops the middle of an oversized result, the second window that walks the tail once the front half is exactly full, per-cell truncation at both call sites, a disabled-warehouse refusal reaching the caller, and a registered URI with no document behind it degrading rather than throwing. ### Verification 14 mutations from the build pass, then three more run independently afterwards — the all-rows-fit `truncated` flag, the empty-result short circuit, and the sliding window evicting the newest row instead of the oldest. All red, production diff empty. Two things worth stating plainly: - **One mutation initially looked like a survivor and was not.** Relaxing the first-row bound from `>=` to `>` appeared to survive, but only because it had been applied alongside two others that together reproduced the same tuple. Re-run in isolation it fails. Batched mutation runs can manufacture false survivors, and this one nearly went into the report as a hole. - **One genuine survivor is an equivalent mutant.** The front-loop bound `frontSize < halfLimit` can be relaxed to `<=` with no observable difference: tuple sizes are strictly positive, so the relaxed loop immediately fails its next fit check and falls into the same window over the same iterator position. Verified by running it. Recorded in a comment rather than chased, and the test that would have claimed it still kills two other mutations. Also, three of my own first-draft mutations were malformed — renaming a private method just breaks compilation, which proves nothing. Re-done against the real code. ### Deliberately not included - **`processedCount`** is written in all three walk paths and never read. The tests execute those lines but assert nothing about it, so deleting the variable stays a safe cleanup. - **`validateWorkflow`** remains dead with zero call sites, still reported rather than tested. - The residual 66 missed lines are live-engine paths — the `Observable.amb` wait, the console-error and results-ready arms, `shutdownPreviousExecution` — plus the dead method above. No production file is touched. ### Any related issues, documentation, discussions? Closes #7603 ### How was this PR tested? ``` STORAGE_ICEBERG_CATALOG_TYPE=postgres sbt "WorkflowExecutionService/testOnly org.apache.texera.web.resource.SyncExecutionResourceSpec" ``` ``` [info] Total number of tests run: 33 [info] Tests: succeeded 33, failed 0, canceled 0, ignored 0, pending 0 ``` 10 new on top of the existing 23. CI already provides what this needs — `build.yml` creates `texera_iceberg_catalog` and sets `STORAGE_ICEBERG_CATALOG_TYPE=postgres` for the unit job — so no workflow change. `Test/scalafmtCheck` and `Test/scalafix --check` both pass. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) -- 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]
