feat: Conditional Execution - Option 1

[camielvs]

Description

Implements Option 1 — Derived. Two alternatives were prototyped alongside it (#2652, #2654); this is the one we settled on. Also a general pass over the UI, UX and frontend architecture of the feature.

The question these options were answering

TaskSpec.isEnabled decides whether a task runs. It either holds a literal ("false") or points at an upstream value — a graph input, or another task's output.

The editor needs to know one thing the spec doesn't record: whether the user wants the conditional UI on this task at all — the extra handle on the node, the condition control in the Config panel. A task with no isEnabled looks exactly like a task that was never meant to be conditional, so where does that piece of state live?

The three answers

• Option 2 — Annotation (feat: Conditional Execution - Option 2 #2652): keep an isConditional annotation on the task, fully decoupled from isEnabled. The annotation controls the UI; isEnabled controls the backend.
• Option 4 — Always-on (feat: Conditonal Execution - Option 4 #2654): don't track it. Show the conditional UI on every task, always.
• Option 1 — Derived (this PR): don't track it either, but infer it. A task is conditional when it has an isEnabled value — a literal on the task, or a connection to the reserved port.

Why derived

Two sources of truth drift, and this one drifts immediately. Pipelines don't only come from our editor — they come from the SDK, from other tools, from hand-written YAML. Those have isEnabled set and no annotation, so the annotation version opens them showing no condition and no edge: the connection is right there in the file and invisible on the canvas. The fix would be to backfill the annotation on import, which is deriving it anyway, one round trip late.

It keeps editor state out of the user's pipeline. Conditional-ness is already expressed by isEnabled. An annotation would write a second copy of it into the file for something we can compute.

Most tasks aren't conditional. Always-on avoids the state problem, but it spends vertical space on every node and adds a concept to every task for the benefit of the few that use it. A switch keeps it opt-in and keeps ordinary nodes looking ordinary.

One question, one answer. isTaskConditional(task, spec) is what the node, the panel and serialization all ask, so they can't disagree.

The honest cost: deriving couples the switch to the value. Turning it on has to write something ("true" — Always), and turning it off has to clear it, so "conditional but not configured yet" isn't a state we can represent. We think that's fine — Always is a sensible starting point, and the alternative was the drift above.

Also in here

• The condition control was a three-way dropdown (Enable task: True / False / Conditional), which folded two different questions into one control — "should this be conditional" and "what's the condition". It's now a switch for the first and a toggle for the second.
• Deleting the condition edge resets the task to enabled instead of resurfacing the previous literal. For an ordinary input, bringing back the old literal when you disconnect it is helpful. For a condition it isn't: resurfacing "false" would leave the task silently disabled after the user deliberately removed the condition.

Related Issue and Pull requests

Stacked on #2574. Alternatives: #2652 (annotation), #2654 (always-on). Followed by #2657, which finishes the UI.

Type of Change

• New feature

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 gates all of this.

1. Select a task → Config tab → toggle Conditional task on, then set the condition to False and confirm the task's isEnabled follows in the YAML.
2. Toggle it back off and confirm isEnabled is cleared and no stray annotation is written.
3. Connect a graph input or an upstream task output to the condition handle, then delete that edge — the task should stay conditional and reset to enabled.
4. Import a pipeline whose YAML sets isEnabled to a reference (e.g. one produced by the SDK) and confirm the editor shows both the conditional UI and the edge without us having written anything into the file first.

Additional Comments

[github-actions]

🎩 Preview

A preview build has been created at: 08-20-feat_conditional_execution_-_option_1/f920c2c

[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
• feat: Finalize Conditional Execution #2657
• feat: Conditional Execution - Option 1 #2651 👈 (View in Graphite)
• 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.