The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-8088-bb56bba107d02616100edd0d1166c6e4d32fc796 has succeeded. Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).
Head commit for run: 512aebde1c6750cc554705aeb783673641981fc8 / Xinyuan Lin <[email protected]> test(amber): cover the end-channel and retry handlers and the range partitioner (#8088) ### What changes were proposed in this PR? Two new specs and one extended, taking the three files from 4 tests to 20. | File | Codecov lines | Branch arms | |---|---|---| | `RetryWorkflowHandler.scala` | 1/5 → **5/5** | no branches | | `EndChannelHandler.scala` | 14/19 → **18/19** | 4/10 → **8/10** | | `RangeBasedShufflePartitioner.scala` | 17/21 → **20/21** | 9/30 → 10/30 | **+11 fully-covered lines and +5 branch arms.** JaCoCo line-hit moves +8 (the two metrics differ because three of the gained lines were already line-hit and flip only by completing a second arm). ### Two files from the original scope contribute nothing, and are named rather than quietly dropped - **`DataProcessorRPCHandlerInitializer`** — the nominated target of this bundle — measured **8/15 before and 8/15 after**. Its only real logic is already covered, and its five remaining lines are `???` stubs that the existing spec deliberately declined to pin. - **`OutputManager`** stays at 98/108. Its storage path looked like the single biggest opportunity here (~18 lines) and it is already covered by the `DataProcessingSpec` end-to-end workflows, which provision real result and state documents. The assessment put this bundle at 25 lines and 15 arms. **It delivered 11 and 5.** The gap was almost entirely one file: `RangeBasedShufflePartitioner` was assessed at +16 on a claimed 4/21 baseline, but the real baseline is 17/21 because **a spec already exists** — `RangeBasedShuffleSpec.scala`, under `messaginglayer` rather than the mirrored `sendsemantics/partitioners` path and without "Partitioner" in its name, which is why a class-name search missed it. That spec was extended in place rather than a duplicate created, and the real win there is +3. ### `retryWorkflow` has no caller in main `RetryWorkflowHandler.retryWorkflow` is invoked from nowhere in `main`. It exists as the declared `rpc RetryWorkflow(RetryWorkflowRequest)` endpoint in `coordinatorservice.proto`, so it is a live API surface rather than dead internal code — but the new spec pins the **RPC contract**, not observed production behaviour, and that distinction is worth stating before someone reads 1/5 → 5/5 as covering a hot path. ### Verification **One survivor, reported rather than killed or dressed up as equivalent.** Exchanging `getAllPorts.forall(portId => isPortCompleted(portId))` for `getAllPorts.forall(p => getPort(p).completed)` at `EndChannelHandler:64` **survives** — measured twice. These are genuinely different predicates: `InputManager.isPortCompleted` branches, and for a port fed from materialization it returns the reader *thread's* `finished` flag and ignores `.completed` entirely. The fixture registers both input ports with empty URI lists, so only the non-materialization branch is ever reachable. Closing it needs storage-backed input ports or a widened private — a production change, refused. **This is an out-of-reach mutant, not an equivalent one**, and the spec's own scaladoc says so, so the next reader does not mistake the two-port fixture for full coverage of the completion predicate. **`EndChannelHandler:54` can never become a fully-covered line** and is not counted as one. It moves 0/4 → 2/4 arms. The two dead arms are the `catch pf` isDefinedAt-false rethrow — dead because `ErrorUtils.safely` returns a *total* PartialFunction — and the `$outer` null guard in the generated anonfun's constructor. Two adversarial reviewers returned ten findings; all repaired. One correction worth naming: two assertions of the form `command == EmptyRequest()` were **guaranteed by the generated type** — `controlcommands.proto:75` is literally `message EmptyRequest{}` with no fields, so every instance equals every other. They were removed rather than left looking like constraints. Measured with one fresh sbt JVM per side, the jacoco directory removed between runs, scoped by **suite name** via a byte-identical throwaway `.sbt` filter that was deleted afterwards. The before-state restored the extended spec with `git show HEAD:<path>` and deleted the two new files — never `git checkout --` — with the final specs sha1-snapshotted first and sha1-verified on restore. Before: 59 suites / 492 tests, 0 failures. After: 61 suites / 508 tests, 0 failures. No production file is touched; `git diff -- '*/src/main/*'` is empty. ### Any related issues, documentation, discussions? Closes #8087 ### How was this PR tested? ``` sbt "WorkflowExecutionService/testOnly org.apache.texera.amber.engine.architecture.worker.promisehandlers.EndChannelHandlerSpec org.apache.texera.amber.engine.architecture.coordinator.promisehandlers.RetryWorkflowHandlerSpec org.apache.texera.amber.engine.architecture.messaginglayer.RangeBasedShuffleSpec" ``` ``` [info] Total number of tests run: 20 [info] Tests: succeeded 20, failed 0, canceled 0, ignored 0, pending 0 [info] All tests passed. ``` `WorkflowExecutionService/Test/scalafmtCheck` and `WorkflowExecutionService/Test/scalafix --check` both pass. Re-run after rebasing onto current `main`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) --------- Signed-off-by: Xinyuan Lin <[email protected]> Co-authored-by: Copilot Autofix powered by AI <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/33240050913 With regards, GitHub Actions via GitBox
