feat: Finalize Conditional Execution - #2657
Conversation
🎩 PreviewA preview build has been created at: |
|
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.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Carry-over audit: does this stack close out #2574's review comments?#2574's comments aren't meant to be actioned there — the expectation is that #2651 and #2657 deal with them. This is the audit of that, posted at the top of the stack so it's in one place. 23 comments on the root PR: 10 resolved, 8 still open, 1 changed shape, 1 partial. Resolved by #2651 / #2657
Still open
Changed shapeBoolean port type / quick-connect compatibility. The original comment was about the Partially addressedAccessible labelling. The Config panel switch now has a real Cross-stack note
|
325c67e to
2d0ce95
Compare
2d0ce95 to
20b5ec3
Compare

Description
Final pass over conditional execution. Nothing changes about what gets sent to the backend — this is UI, vocabulary and test coverage. The visual direction is borrowed from the exploration in #2649.
"Run when", not "isEnabled".
isEnabledis spec jargon. The UI now says Run when, and the two literal choices read Always / Never rather than true/false.Conditional execution gets its own purple box in the Config tab. A single switch turns it on for a task. When it's on, the Run when control appears inside the box — either the Always/Never toggle, or, if something is wired into it, the upstream source it follows (
→ Flag.flag), formatted the same way bound inputs are formatted everywhere else in the editor.On the node, the condition is separate from the inputs. It used to be injected into the task's input list as a fake input, which meant the list had to know about it in every place it did anything (splitting, condensing, counting). It's now its own purple row above the inputs with its own handle, which means:
Dragging off the "Run when" handle no longer creates a graph input called
__is_enabled__. The editor names an auto-created input after the port you dragged from, and the reserved port name was leaking into the user's pipeline. It now creates an input calledrun_condition, typedString— that's the form the condition is actually read in, and it's what lets the input connect to the ports components declare.Naming and comments. Internal names now say what they are (
resetRunCondition,runConditionBinding,setRunCondition, …). Comments that narrated the code were deleted; the ones left explain a decision the code can't.Tests. New coverage for the shared helpers, the enable/disable actions (including that switching conditional execution off clears both the literal and the connection while leaving other connections alone), the node rendering, the auto-created input, and each of the fixes below.
Fixes from review
false. That now reads as Never; before, it showed as Always while the backend skipped the task — the display and the behaviour disagreed.run_conditioninput, and a fixed condition survives the round trip.Related Issue and Pull requests
Stacked on #2651. UI direction borrowed from #2649. Followed by #2658, which stops conditional execution being set where the backend won't honour it.
Type of Change
Checklist
Screenshots (if applicable)
Test Instructions
The
conditional-executionflag is off by default — turn it on in Settings first.run_conditionString graph input, not one named__is_enabled__.false, and the task should still read as gated off — not silently switch to running.→ Task.output.false(no quotes), then open it. The task should read Never.__is_enabled__should appear anywhere.Additional Comments
Turning conditional execution off deliberately clears the condition (both the literal and any connection) rather than remembering it, so re-enabling starts from Always. That's the trade discussed in #2651.