Task Summary
#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 — pre-publish failures (inside new WorkflowExecutionService(...), before executionService.onNext(...)) are reported directly via errorSubject, while post-publish failures surface through the metadata-store diff handler. This works (reviewed as a fair design), but error reporting lives in two places. Per @Yicong-Huang, consolidate to a single reporting site bundled with WorkflowExecutionService: (1) make 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, so any error during init() is reported by the logic already wired during construction. Benefit: a single error-reporting site owned by WorkflowExecutionService, removing the two-phase split (and the errorSubject fallback) in WorkflowService.initExecutionService. Challenge: the current constructor performs external calls; making it side-effect-free requires moving those into init() without breaking call sites that depend on construction side effects. Follow-up to #5781.
Task Type
Task Summary
#5781 surfaces init-time fatal errors to the frontend. Because
WorkflowExecutionServiceconstruction itself can throw (it makes external calls), that fix uses two reporting phases inWorkflowService.initExecutionService— pre-publish failures (insidenew WorkflowExecutionService(...), beforeexecutionService.onNext(...)) are reported directly viaerrorSubject, while post-publish failures surface through the metadata-store diff handler. This works (reviewed as a fair design), but error reporting lives in two places. Per @Yicong-Huang, consolidate to a single reporting site bundled withWorkflowExecutionService: (1) make 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 separateinit()phase run after construction, so any error duringinit()is reported by the logic already wired during construction. Benefit: a single error-reporting site owned byWorkflowExecutionService, removing the two-phase split (and theerrorSubjectfallback) inWorkflowService.initExecutionService. Challenge: the current constructor performs external calls; making it side-effect-free requires moving those intoinit()without breaking call sites that depend on construction side effects. Follow-up to #5781.Task Type