kz930 opened a new pull request, #7983: URL: https://github.com/apache/texera/pull/7983
### What changes were proposed in this PR? The run button's enabled state comes from `ValidationWorkflowService` alone. That service checks two things per operator: the operator's properties against its JSON schema with ajv, and whether every input port is connected. Neither reads the compiling service, so a workflow whose operators fail to compile is still offered for execution, and pressing run starts an execution that reports the same compilation error in the console. `CompilationState.Failed` reaches the frontend but its only consumer outside the compiling service decides whether the error panel is shown. This PR subscribes the menu to the compiling service's state stream and treats a failed compilation the same way as a validation error. The button reads "Invalid Workflow" and is disabled, and `runWorkflow` returns early on the same flag. Reusing the existing text and icon keeps one code path for "this workflow is not runnable", and the operator's red cross and the error panel already say which operator is at fault and why. Two notes on the shape of the guard. An HTTP failure of the compile endpoint yields no state change rather than a failed one, so a compiling service that is down cannot brick the button. And compilation is debounced, so the button flips a moment after an edit, which is already true of the red cross and the error panel. The context menu's "execute to this operator" gets the same guard. Because that entry runs the target together with everything upstream of it, it checks the target's sub-DAG against the compilation error map rather than only the target operator. An error elsewhere in the workflow leaves the entry enabled for an operator whose own upstream compiles. ### Any related issues, documentation, discussions? Closes #7981. Also covers the context menu entry that #3068 asked about. ### How was this PR tested? Six unit tests were added. In the menu spec: the run descriptor when the workflow does not compile, `runWorkflow` declining to submit on the same flag, and the stream wiring in both directions. In the context menu spec: the target operator failing to compile, an upstream operator failing to compile, and a compilation error outside the target's sub-DAG leaving the entry enabled. The compiling service is stubbed in the menu spec so its debounced compile request does not outlive the test injector. The two specs run 146 tests and pass. Manually verified against the reproduction in the issue, on a CSV with a text column and a numeric label, wired to Gaussian Naive Bayes on both the training and the testing port. With Count Vectorizer on and Text Attribute empty the button reads "Invalid Workflow" from ajv, as before. Filling Text Attribute in satisfies ajv, and the button now stays disabled instead of turning into Run, with the workflow reported as valid but not compilable. The context menu entry is disabled on the Gaussian Naive Bayes operator and still enabled on the upstream CSV File Scan. Turning Count Vectorizer back off returns the button to Run. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 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]
