fix: Do not allow conditional execution on Subgraph Nodes + Validations

[camielvs]

Description

Conditional execution only works on tasks that run a container. The backend rejects it on subgraphs, so a pipeline that gates one fails at submission with a raw error the user can't act on.

The control is hidden for subgraphs. The Conditional execution box no longer appears when the selected node is a subgraph, so it can't be switched on by accident.

Validation covers what hiding the control can't. A pipeline can arrive with the condition already set — from the SDK, from hand-written YAML, or from an earlier version of the editor. A subgraph with a run condition is now flagged as an error that blocks submission, with a Remove Condition fix offered in the issue panel.

Three related checks, since the same panel was already open:

• A component that declares an input named __is_enabled__ collides with the name the editor reserves for run conditions. Connecting such an input would silently save it as the task's run condition and drop the argument. It's a warning as soon as the component is used, and an error once the input is actually connected.
• A condition wired to a value that can't be read as true or false — a number, say — is an error. Anything else blocks submission too, and for the same reason: the run doesn't fail up front, it fails at the moment the task is reached, after everything upstream has already spent its compute. Catching it before submission is worth doing.
• A fixed condition that isn't true or false — someone's hand-written yes, or a value the editor can't make sense of — is an error, and the message quotes the offending value. Casing and stray whitespace are fine. A condition that's wired up rather than fixed is left alone, since its value isn't known until the run.

Related Issue and Pull requests

Stacked on #2657.

Type of Change

• Bug fix

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

Test Instructions

The conditional-execution flag is off by default — turn it on in Settings first.

1. Select a subgraph node → Config tab. There should be no Conditional execution box. Select an ordinary task and confirm it's still there.
2. Hand-edit a pipeline's YAML so a subgraph task is gated on a condition, then open it. The issue panel should show an error, submission should be blocked, and Remove Condition should clear it.
3. Gate an ordinary task on a number-typed output. You should get an error explaining the value can't be read as a condition, and submission should be blocked. Re-wire it to a String or Boolean output and the error should clear.
4. Hand-edit a task's condition to something like yes. You should get an error quoting that value. Change it to TRUE or false and it should be accepted.

Additional Comments

The reserved-name check is a guard against a name collision rather than something a user is likely to hit — a component would have to declare an input called __is_enabled__. It's here because the failure is silent: the argument disappears on save with nothing to indicate why.

The type check accepts str, bool and text alongside the canonical type names. Since it blocks submission, a hand-written component using a lowercase alias shouldn't be caught by it.

One thing deliberately not done: the accepted conditions aren't normalized on load. The checks read leniently but write nothing — quietly rewriting a value in someone's pipeline is worse than reporting it.

[github-actions]

🎩 Preview

A preview build has been created at: 08-20-fix_do_not_allow_conditional_execution_on_subgraph_nodes/f389987

[camielvs]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix: Do not allow conditional execution on Subgraph Nodes + Validations #2658 👈 (View in Graphite)
• feat: Finalize Conditional Execution #2657
• feat: Conditional Execution - Option 1 #2651
• feat: Pipeline editor - Conditional execution #2574 : 2 other dependent PRs (#2652 , #2654 )
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.