Skip to content

feat(gui): gate workflow execution on the compilation state - #7983

Open
kz930 wants to merge 1 commit into
apache:mainfrom
kz930:feat/gate-run-on-compilation-state
Open

feat(gui): gate workflow execution on the compilation state#7983
kz930 wants to merge 1 commit into
apache:mainfrom
kz930:feat/gate-run-on-compilation-state

Conversation

@kz930

@kz930 kz930 commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

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)

The run button's enabled state came from ValidationWorkflowService alone,
which checks an operator's properties against its JSON schema and whether
every input port is connected. Neither reads the compiling service, so a
workflow whose operators fail to compile was still offered for execution,
and pressing run started an execution that reported the same compilation
error in the console.

Subscribe the menu to the compiling service's state stream and treat a
failed compilation the same way as a validation error: the button reads
"Invalid Workflow" and is disabled, and runWorkflow returns early. An HTTP
failure of the compile endpoint yields no state change rather than a
failed one, so a compiling service that is down cannot disable the button.

The context menu's "execute to this operator" runs the target together
with everything upstream of it, so it is disabled when any operator in the
target's sub-DAG failed to compile, not only the target itself.

Closes apache#7981

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions github-actions Bot added feature frontend Changes related to the frontend GUI labels Aug 26, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

  • Contributors with relevant context: @mengw15, @zyratlo, @Yicong-Huang
    You can notify them by mentioning @mengw15, @zyratlo, @Yicong-Huang in a comment.

@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.14%. Comparing base (7fbf64e) to head (bba4e2e).

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #7983      +/-   ##
============================================
- Coverage     93.14%   93.14%   -0.01%     
  Complexity     4654     4654              
============================================
  Files          1174     1174              
  Lines         47580    47592      +12     
  Branches       5316     5316              
============================================
+ Hits          44318    44329      +11     
  Misses         1785     1785              
- Partials       1477     1478       +1     
Flag Coverage Δ *Carryforward flag
access-control-service 81.00% <ø> (ø) Carriedforward from 7fbf64e
agent-service 99.32% <ø> (ø) Carriedforward from 7fbf64e
amber 89.23% <ø> (ø) Carriedforward from 7fbf64e
computing-unit-managing-service 73.67% <ø> (ø) Carriedforward from 7fbf64e
config-service 86.73% <ø> (ø) Carriedforward from 7fbf64e
file-service 85.56% <ø> (ø) Carriedforward from 7fbf64e
frontend 95.64% <100.00%> (-0.01%) ⬇️
notebook-migration-service 79.31% <ø> (ø) Carriedforward from 7fbf64e
pyamber 97.57% <ø> (ø) Carriedforward from 7fbf64e
workflow-compiling-service 77.19% <ø> (ø) Carriedforward from 7fbf64e

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@kz930

kz930 commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

/request-review @aglinxinyuan @carloea2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature frontend Changes related to the frontend GUI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The Run button ignores compilation errors, so a workflow that cannot compile still starts

2 participants