sshiv012 opened a new pull request, #9015:
URL: https://github.com/apache/texera/pull/9015
### What changes were proposed in this PR?
#8668 tags a failed worker RPC with the worker it targeted
(`WorkflowRuntimeException` with `relatedWorkerId`), so the surfaced error can
point at that worker. But the worker is dropped one hop later: the coordinator
returns the error to the web service as a `ControlError`, which has no field
for it, and `ErrorUtils.reconstructThrowable` rebuilds a plain `Throwable`.
`WorkflowService`'s error handler then finds no worker and records the error as
"unknown operator".
You can see this with a Python UDF that fails while starting (e.g. the
default template, which has no class). The coordinator log shows
`WorkflowRuntimeException … Worker:WF23-PythonUDFV2-operator-udfdemo-main-0`,
but the UI gets `operatorId: "unknown operator"`. So clicking the failed UDF
shows only an empty Console and no error.
This PR carries the worker the rest of the way:
- `ControlError` gets an optional `relatedWorkerId`
(`core.ActorVirtualIdentity`).
- `mkControlError` fills it from a `WorkflowRuntimeException`.
- `reconstructThrowable` rebuilds a `WorkflowRuntimeException` with that
worker when the field is set, so `WorkflowService` maps the error to the
failing operator.
Errors without a worker are unchanged.
### Any related issues, documentation, discussions?
Follow-up to #8668 (issue #8667). Part of #8736. With this, #8771 no longer
needs a frontend workaround to show a failed UDF's startup error when the UDF
is clicked.
### How was this PR tested?
- New specs in `ErrorUtilsSpec`:
- `mkControlError` carries the worker of a `WorkflowRuntimeException`, and
leaves it empty otherwise;
- `reconstructThrowable` rebuilds a `WorkflowRuntimeException` with the
worker, message and cause;
- the rebuilt error maps to the right operator id via
`getOperatorFromActorIdOpt`;
- errors without a worker still rebuild a plain `Throwable`.
- The two existing specs that build a `ControlError` directly pass the new
field (`None`).
```
sbt "WorkflowExecutionService/testOnly
org.apache.texera.amber.error.ErrorUtilsSpec
org.apache.texera.amber.engine.architecture.scheduling.RegionExecutionManagerSpec
org.apache.texera.amber.engine.architecture.scheduling.WorkflowExecutionManagerSpec"
sbt "WorkflowExecutionService/scalafmtCheck"
"WorkflowExecutionService/Test/scalafmtCheck"
"WorkflowExecutionService/scalafixAll --check"
bash bin/python-proto-gen.sh && cd amber && pytest -m "not integration"
```
End to end, on a local Texera built from current main plus this PR and #8771
(which no longer has a frontend filter), I ran a Python UDF that fails while
starting:
| | `operatorId` the UI receives | Clicking the failed UDF |
|---|---|---|
| main | `"unknown operator"` (`workerId` empty) | only an empty Console |
| this PR | `"PythonUDFV2-operator-udfdemo"` (`workerId`
`Worker:WF23-PythonUDFV2-operator-udfdemo-main-0`) | a Static Error tab next to
the Console, with the error |
The message also loses its `java.lang.Throwable:` prefix, since the rebuilt
`WorkflowRuntimeException` prints just its message.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 5.5)
--
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]
