The GitHub Actions job "Required Checks" on texera.git/main has succeeded. Run started by GitHub user github-merge-queue[bot] (triggered by github-merge-queue[bot]).
Head commit for run: e42f6b3651208e6d93d1069e02bf870ee707b0d7 / Yicong Huang <[email protected]> fix(amber): persist operator port result URIs through a ClientEvent (#5434) ### What changes were proposed in this PR? `WorkflowExecutionsResource.insertOperatorPortResultUri` was a static method on a JAX-RS resource that the engine (`RegionExecutionManager`, named `RegionExecutionCoordinator` before #6123) called directly to write `operator_port_executions` rows — two layering problems in one helper: a JAX-RS resource that wasn't an HTTP endpoint, and an engine actor reaching across into the web layer to write the DB. The fix follows the codebase's existing engine→web channel. Engine actors call `asyncRPCClient.sendToClient(event: ClientEvent)`; web services call `client.registerCallback[T](handler)` to react. `RuntimeStatisticsPersist` is the closest precedent — engine emits, `ExecutionStatsService` writes the DB. Concretely: - Add `OperatorPortResultUriAvailable(globalPortId, uri)` to `ClientEvent`. The event is execution-scoped, so it carries no `eid` — the subscriber already holds its own `executionId`, which also removes the old `decodeURI(resultURI)` round-trip in `RegionExecutionManager`. - `RegionExecutionManager` emits this event in place of calling the web helper. - `ExecutionResultService.attachToExecution` registers a callback that inserts the row via the generated `OperatorPortExecutionsDao` (extracted as `ExecutionResultService.persistOperatorPortResultUri` so tests can drive the same insert). The registration site carries a comment documenting the ordering invariant: the callback must be attached before `startWorkflow`, otherwise result URIs are silently never persisted. - Delete `WorkflowExecutionsResource.insertOperatorPortResultUri`. The engine no longer imports `WorkflowExecutionsResource`; the resource spec inserts its fixture rows through `OperatorPortExecutionsDao` directly. - E2E specs (`DataProcessingSpec`, reconfiguration specs) register the same production callback body via `TestUtils.registerResultUriPersistence` and read results back through `getResultUriByLogicalPortId`, so the event→DB-insert seam stays covered end to end. ### Any related issues, documentation, discussions? Closes #5430. Sub-issue of #5424 — eliminates one of the four engine→web import leaks blocking the amber Dropwizard upgrade tracked in #5423. ### How was this PR tested? `sbt 'WorkflowExecutionService/testOnly *ExecutionResultServiceSpec *WorkflowExecutionsResourceSpec *DataProcessingSpec *ReconfigurationSpec'` — 58 tests pass across the 4 affected suites. `sbt scalafmtCheckAll` clean. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.7) Report URL: https://github.com/apache/texera/actions/runs/28732239637 With regards, GitHub Actions via GitBox
