[I] Cover result pagination and the result update loop [texera]

["aglinxinyuan (via GitHub)" <gi...@apache.org>]

aglinxinyuan opened a new issue, #7555:
URL: https://github.com/apache/texera/issues/7555

   ### Task Summary
   
   `amber/src/main/scala/org/apache/texera/web/service/ExecutionResultService.scala` sits at **22.9% of 122 lines** (94 missed). A spec exists — `ExecutionResultServiceSpec`, 18 tests — but it covers the JSON conversion helpers and the `WebOutputMode` round-trips and stops at the class's own behaviour. Nothing exercises the paths a user actually hits:
   
   - **`handleResultPagination`** — the page origin and range end, case-insensitive `columnSearch`, `columnOffset`/`columnLimit` slicing, the warehouse read guard, and the empty-page response when an operator has no stored result.
   - **`convertWebResultUpdate`** — all three output modes, the internal-port filter, the dirty-page computation, and snapshot versus delta reads.
   - **The polling loop** — the terminal-state transition that cancels polling and runs one final update, and the fatal-error path.
   
   The seam is `attachToExecution(executionId, stateStore, physicalPlan, client)`. `AmberClient` is non-final and `registerCallback[T]` is overridable, so a test subclass captures the registrations and fires them directly; construct it over a bare `ActorSystem` created in `beforeAll`, exactly as `ExecutionConsoleServiceSpec` does — `Await.result(clientActor ? InitializeRequest(...))` completes on an empty plan with no engine. Pass a fresh `ExecutionStateStore` and never push RUNNING through it, which is what keeps `AmberRuntime` untouched.
   
   **Measurement trap worth writing down.** A plain `testOnly` produces a **0% jacoco report** for this module — the destfile javaOption only comes from the `jacoco` task. Use the filter-plus-jacoco form:
   
   ```
   sbt 'set WorkflowExecutionService/Test/testOptions += Tests.Filter(n => n.endsWith("ExecutionResultServiceSpec"))' "WorkflowExecutionService/jacoco"
   ```
   
   then parse `amber/target/scala-2.13/jacoco/report/jacoco.xml`. Without the filter, a bare `jacoco` runs amber's `@IntegrationTest` specs, which hang on Windows.
   
   One line is genuinely unreachable and should be **deleted rather than tested**: the `case _ => throw new RuntimeException("update mode combination not supported: ...")` in `convertWebResultUpdate`. `webOutputMode` is built immediately above from a total match over `OutputMode`, so it is provably one of `PaginationMode` / `SetSnapshotMode` / `SetDeltaMode`, and all three are matched by the preceding cases.
   
   ### 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: notifications-unsubscribe@texera.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Cover result pagination and the result update loop [texera]

["aglinxinyuan (via GitHub)" <gi...@apache.org>]

aglinxinyuan closed issue #7555: Cover result pagination and the result update loop
URL: https://github.com/apache/texera/issues/7555


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org