feat: Pipeline editor - Conditional execution

[Ark-kun]

Description

Adds support for the conditional execution feature (TaskSpec.isEnabled). When user selects a Task node, the Config tab in right sidebar allows the user to configure "Enable task": The user can set it to "True" (default) "False" or "Conditional".

• True: Unset TaskSpec.isEnabled
• False: Set TaskSpec.isEnabled to "false"
• Conditional: Adds a new virtual input named "Is enabled?" to the tasks's node visual representation. The user can connect something (task output, graph input) to that input just like with normal inputs. Internally, the connected argument is assigned to the TaskSpec.isEnabled attribute (similar to TaskSpec.arguments["..."]).

Backend PR: TangleML/tangle#301

Related Issue and Pull requests

Type of Change

• Bug fix
• New feature
• Improvement
• Cleanup/Refactor
• Breaking change
• Documentation update

Checklist

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

Screenshots (if applicable)

Test Instructions

Additional Comments

[github-actions]

🎩 Preview

A preview build has been created at: feat--Conditional-execution/9c91bfc

[camielvs]

🤖 This is an AI-generated code review comment.

The inline comments cover the line-anchored issues. A few findings are cross-cutting or land outside this PR’s diff, so collecting them here.

Design consequence — sentinel leaks through createSubgraph

createSubgraph.ts promotes each incoming boundary binding to a graph input whose name is first.targetPortName. So wrapping a gated task whose gate source sits outside the selection mints a user-visible pipeline input named __is_enabled__. Relatedly, any component that legitimately declares an input named __is_enabled__ would have its real argument swallowed into isEnabled. The reserved-port approach is the right call, but subgraph promotion (and packing/unpacking) needs to special-case the sentinel. (Line is outside this PR’s diff, hence not inline.)

UX gaps

• No canvas signal for a disabled task. isEnabled: "false" renders identically to an enabled task — you must select the node and open Config to see it. Highest value-per-line addition here: dim the node or add a badge.
• “Conditional” with nothing wired is a silent no-op. It serializes to no isEnabled and the task just runs. The only signal is subdued sidebar text on a normally-closed panel, and validateSpec has no rule. Add a warning issue so it surfaces in the normal pre-submit flow.
• Bad upstream value → mid-run System Error (the case Maksym hit in the thread). An empty output takes a different backend branch and produces the misleading “does not have value” text — worth a backend message fix (Alexey). On the UI side, warn when the connected output’s declared type isn’t String/Boolean.
• No beta flag (as Camiel requested in the thread). ExistingFlags + useFlagValue is ~3 lines. Gate display only (the select item + the virtual port) — never the serializers, otherwise a spec authored flag-on becomes lossy for a flag-off user.

Test gaps

• setEnableTaskMode transitions — binding cleanup when leaving conditional, and undo grouping.
• Subgraph rejection of the “Enable task” control.
• createSubgraph / unpackSubgraph carrying a task with a conditional binding.
• Boolean and uppercase/whitespace isEnabled literals.

Verdict

Design is right, execution mostly clean. Modeling the gate as an ordinary binding to a reserved port — rather than a bespoke widget — means edges, undo, copy/paste, and round-trip all come for free, and the serializer/deserializer tests are solid. Dropping the never-implemented PredicateType for ArgumentType makes the type honest. The three inline-flagged bugs (subgraph gate, literal normalization, fail-open dangling reference) are the blockers.

[camielvs]

@Ark-kun most of the Ai's findings above we can address in a follow-up once we have this shipped under a beta flag. I already have some notes and thoughts about how we can improve canvas UX for various conditional states

[Ark-kun]

@Ark-kun most of the Ai's findings above we can address in a follow-up once we have this shipped under a beta flag. I already have some notes and thoughts about how we can improve canvas UX for various conditional states

Thank you, @camielvs . I've added a beta flag.

[camielvs]

Let's ship this and I will follow-up with improvements and address the AI review when I have time

[camielvs]

actually, let's hold for now. I will prioritize checking for an alternative system than annotation-based as it may be irreversivble if we commit now.

Give me a couple days :)

need to do a bit or tech research before verify and accepting this approach

[camielvs]

• feat: Pipeline editor - Conditional execution #2574 : 3 dependent PRs (#2651 , #2652 , #2654 ) 👈 (View in Graphite)
• master

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

[camielvs]

Approved as part of the upstream conditional execution stack, which refines the frontend architecture and UX