The GitHub Actions job "Required Checks" on 
texera.git/gh-readonly-queue/main/pr-7604-289189741dad32c7d613108ecd9fe75a8eca420d
 has succeeded.
Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).

Head commit for run:
befcf3f0813371c8dd351bc962b70c1bdc94f4b1 / Xinyuan Lin <[email protected]>
test(amber): cover the sync endpoint's result truncation engine (#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)

Report URL: https://github.com/apache/texera/actions/runs/31670506628

With regards,
GitHub Actions via GitBox

Reply via email to