Yicong-Huang opened a new pull request, #4515:
URL: https://github.com/apache/texera/pull/4515
### What changes were proposed in this PR?
`ResumeHandler.resumeWorkflow` (`ResumeHandler.scala`) finished by sending
`ExecutionStatsUpdate` and `RuntimeStatisticsPersist` to the client but never
sent `ExecutionStateUpdate`. `PauseHandler.scala:88-90` emits the corresponding
state event at the end of pause, so the asymmetry meant clients (and tests) had
no event-driven signal for the resume → RUNNING transition.
The aggregated state is already correct on the server side after the
per-worker resume futures resolve (each `workerInterface.resumeWorker(...)`
returns a `WorkerStateResponse` and `ResumeHandler` updates the internal
`WorkerExecution` state with that result, so `cp.workflowExecution.getState`
returns `RUNNING`). The fix is to broadcast it:
```diff
sendToClient(ExecutionStatsUpdate(stats))
sendToClient(RuntimeStatisticsPersist(stats))
+sendToClient(ExecutionStateUpdate(cp.workflowExecution.getState))
```
### Any related issues, documentation, discussions?
Closes #4514
### How was this PR tested?
`sbt WorkflowExecutionService/compile` succeeds; `scalafmtCheckAll` clean.
The two existing consumers of `ExecutionStateUpdate`
(`ExecutionStatsService.scala:209` and `ExecutionConsoleService.scala:204`)
already handle `WorkflowAggregatedState.Recognized`, so an additional `RUNNING`
emit at resume time is a strictly additive event. No existing test asserts the
absence of this event. Relying on CI for the full backend test run.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.7)
--
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]
