aglinxinyuan opened a new issue, #7956: URL: https://github.com/apache/texera/issues/7956
### Task Summary Two files in the AsterixDB source family, where the gap is almost entirely unclosed branch arms on lines that already execute — the case Codecov penalises and JaCoCo's line-hit counter hides: | File | Coverage | |---|---| | `.../asterixdb/AsterixDBSourceOpDesc.scala` | 84.0% — 0 missed, **8 partial** of 50 lines | | `.../asterixdb/AsterixDBSourceOpExec.scala` | 87.5% — 1 missed, 12 partial of 104 lines | The `OpExec` half was assessed earlier in this campaign and found worth about **1 line**, so expect the `OpDesc` half to carry the bundle. Traps and structural limits, all verifiable with `javap`: 1. **`AsterixDBSourceOpExec:331` can never be fully covered.** For the `| _` alternate, scalac pushes `iconst_1` unconditionally, so the `ifeq` has a permanently dead side. 2. **Lines 227 and 239 need an `Attribute` carrying a null `AttributeType`** — the null-comparison arms of scalac's `==` expansion. Not constructible from a real descriptor. 3. **Line 152's `if (values == null) return null` is dead**: `CSVParser.parse` returns a `scala.Option`, so `values` is never a Java null. 4. **Line 268 re-checks a condition its only caller already guarded**, so the false arm cannot occur. 5. **A stub that answers any statement identically makes the query assertions vacuous.** Record the decoded statements and assert on them, or an exchanged query passes. 6. **Module traps, both confirmed twice in this campaign:** `WorkflowOperator/jacoco` fails inside a git worktree because `FileScanSourceOpExecSpec` aborts in `beforeAll` with `RepositoryNotFoundException` (a worktree's `.git` is a file), and since sbt-jacoco runs unforked the report comes out **all-zero** rather than partial — exclude that suite by name in *both* runs, and delete the untracked `test_large_binary.txt` its aborted teardown leaks. And module-wide branch totals are not quotable here, because `IntervalJoinOpExec`'s covering spec uses an unseeded RNG whose branch count drifts run to run. One defect is worth knowing and **should not be pinned**: after `hasNext` then `close()`, a fresh `produceTuple()` still hands out the previously peeked row, because `close()` clears the iterator and query string but not the cached tuple. Pinning either side would cement a decision that has not been made. ### 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]
