aglinxinyuan opened a new issue, #5921: URL: https://github.com/apache/texera/issues/5921
### Context #5781 surfaces init-time fatal errors to the frontend. Because `WorkflowExecutionService` construction itself can throw (it makes external calls), that fix uses **two** reporting phases in `WorkflowService.initExecutionService`: 1. **Pre-publish** — a failure inside `new WorkflowExecutionService(...)`, before `executionService.onNext(...)` publishes it: reported directly via `errorSubject`. 2. **Post-publish** — a failure after the execution is published: the metadata-store diff handler emits a `WorkflowErrorEvent`. This works (and was reviewed as a fair design), but error reporting lives in two places. ### Proposed refactor (per @Yicong-Huang) Consolidate to a **single reporting site bundled with `WorkflowExecutionService`**: 1. Make `WorkflowExecutionService` **construction error-free** — no external calls (DB inserts, controller/client creation, etc.) — and register the error-reporting (`fatalErrors` → `WorkflowErrorEvent`) diff handler as the **first** construction action. 2. Move the throwing work into a separate **`init()`** phase run after construction. Any error during `init()` is then reported by the logic already wired during construction. ### Benefit Single error-reporting site, owned by `WorkflowExecutionService` — removes the two-phase split (and the `errorSubject` fallback) in `WorkflowService.initExecutionService`. ### Challenge The current constructor performs external calls; making it genuinely side-effect-free requires moving those into `init()` without breaking call sites that depend on construction side effects. Follow-up to #5781. -- 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]
