aglinxinyuan opened a new pull request, #7989: URL: https://github.com/apache/texera/pull/7989
### What changes were proposed in this PR? Three small workflow-operator gaps, bundled because none is worth a PR alone. 31 tests across the three specs, one of which is new. Measured with two `WorkflowOperator/jacoco` runs, one fresh sbt batch JVM each, `rm -rf` on the jacoco dir between them, and the identical suite-name filter both times. The before run **reproduced all published Codecov percentages exactly** (88.2 / 90.5 / 88.0 / 85.2 / 83.3), which validates the method. | File | Codecov | JaCoCo line-hit | |---|---|---| | `HuggingFaceSentimentAnalysisOpDesc.scala` | 22/25 = 88.0% → **25/25 = 100%** | 100% → 100% | | `BarChartOpDesc.scala` | 30/34 = 88.2% → **32/34 = 94.1%** | 33/34 → **34/34 = 100%** | | `RandomUserAgent.java` | 23/27 = 85.2% → **26/27** | — | **+8 fully-covered lines and 9 branch arms closed.** Worth noting the shape of the sentiment descriptor: its line-hit was *already* 100%, so its entire gain is partial arms flipping to hits — arms covered went 7 → 12, missed 5 → 0. That is precisely the case Codecov penalises and line-hit hides. `HashJoinProbeOpExec` and `OPVersion.java` were in the original scope and are **absent** — neither survived assessment, and padding the bundle with them would have added nothing. ### Verification 22 mutations. **19 non-equivalent mutants, all 19 killed**, each kill re-derived from scratch with the failing test name and assertion line read out of the ScalaTest XML — the sbt log never names them. The first draft reported no survivors. **It shipped with at least seven live semantic survivors**, all seven re-derived here against a hash-verified tree. **Three mutants survived and are recorded as equivalent, deliberately run to prove a point:** a label-map pair reorder, an empty-cell fill-tuple reorder, and a `getOutputSchemas` guard-clause reorder. Each was applied specifically to demonstrate that the new assertions check *containment and identity* rather than incidental ordering — i.e. they are not over-fitted. The guard-clause one is a pure `||` over side-effect-free predicates, and is distinct from two sibling mutants that swap the variable *inside* a clause, both of which die. ### A mechanism I had wrong, corrected here Every brief in this campaign has said that `FileScanSourceOpExecSpec` aborts inside a git worktree because a worktree's `.git` is a file, throwing `RepositoryNotFoundException` in `beforeAll`. **That is wrong.** Run unfiltered, the suite runs its 7 tests successfully and then aborts at *suite* level with: ``` java.nio.file.FileSystemException: ...test_large_binary.txt: The process cannot access the file because it is being used by another process ``` — a Windows file-lock in its own cleanup, because a reader is still open. The `RepositoryNotFoundException` in the same log comes from `OPVersion.<clinit>` → `LogicalOp.getOperatorVersion`, is caught by `OPVersion`'s own try/catch, and has nothing to do with the abort. The exclusion is still the right call for measurement, but the corrected mechanism carries a consequence the wrong one hid: on any unfiltered run that file **is** leaked into the source tree, so it must be deleted before committing or it trips the licence-header check. The earlier claim that "`find` confirms none exists" was true only because that suite was never allowed to run. Module-wide branch totals are not quoted here, because `IntervalJoinOpExec`'s covering spec uses an unseeded RNG whose branch count drifts run to run. ### Deliberately not included `BarChartOpDesc` keeps two partial lines (108 and 114, mb3/cb3 and mb3/cb5), so 32/34 is its ceiling under a test-only change. Both descriptor specs carry a JSON round-trip test per house convention, and no descriptor subclass is defined in any spec — `PythonCodeRawInvalidTextSpec` instantiates every subclass by reflection, so a test-only subtype would break it. The new spec carries the Apache licence header. No production file is touched, and no stray `test_large_binary.txt` was left behind. ### Any related issues, documentation, discussions? Closes #7987 ### How was this PR tested? ``` sbt "WorkflowOperator/testOnly org.apache.texera.amber.operator.visualization.barChart.BarChartOpDescSpec org.apache.texera.amber.operator.huggingFace.HuggingFaceSentimentAnalysisOpDescSpec org.apache.texera.amber.operator.source.fetcher.RandomUserAgentSpec" ``` ``` [info] Total number of tests run: 31 [info] Tests: succeeded 31, failed 0, canceled 0, ignored 0, pending 0 ``` Both full-module runs were green (2365 → 2379 tests, 289 → 290 suites, zero failures), so neither report is the all-zero artifact. `Test/scalafmtCheck` passes. ### 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]
