Repository navigation
feat(webapp): run a workflow from the editor and watch it node by node - #533
Merged
Merged
Conversation
LeadcodeDev
added this pull request to stack #531
September 17, 2026 08:21
Starting a run navigated away to the inspector, so the graph you had just built disappeared at the moment it became interesting to watch. It now stays: the dialog closes, the run starts, and the editor colours itself. Each connector carries the status of its own step — amber while running, green once succeeded, red on failure. A connector with no step, or one still pending, is left alone rather than dressed in a colour that would claim more than the engine has said. The run id is not threaded between the two sibling features. The canvas already fetched the workflow's latest run to feed the available-data tree, so it simply polls that one instead, through `useRunPolling`, which stops of its own accord at a terminal status. Starting a run invalidates the run list, so the newly created run becomes the latest and the canvas picks it up with nothing to wire between components. This is polling rather than push because the run engine emits no realtime event: none of its `#[transactional]` methods lists `events`. Making the engine publish per-step progress is a backend change of its own, and worth doing before this feature is asked to scale past one editor tab. `Historique d'exécution` still navigates — only the post-start jump is gone.
The available-data tree made you pick between the example payload and the last run's real values before it would show you anything. Two of the three states that toggle could be in were useless: the example once a run exists, and a disabled last-run button before one does. It now shows the last run's values when there is a run, and the example until then. Nothing to choose, and the panel stops carrying a control whose only job was to be in the wrong position. The three tests covering the toggle are deleted — their subject is gone. The one whose intent survived is rewritten rather than dropped: the tree does still show real values once a run exists, just without a button, and a companion now pins the fallback to the example while no run has happened.
LeadcodeDev
force-pushed
the
feature/automation-run-in-editor
branch
from
September 17, 2026 10:54
04a6b97 to
c07f533
Compare
Contributor
|
🚀 Preview deployed: https://pr-533.mestier.fr Synced revision |
Congrats! CodSpeed is installed 🎉
You will start to see performance impacts in the reports once the benchmarks are run from your default branch.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #530 (WS4) — review that one first; this diff shrinks to its own commit once WS4 merges.
What changed
Starting a run navigated away to the inspector, so the graph you had just built disappeared at the moment it became interesting to watch. It now stays: the dialog closes, the run starts, and the editor colours itself.
Each connector carries the status of its own step — amber while running, green once succeeded, red on failure. A connector with no step, or one still pending, is left alone rather than dressed in a colour that would claim more than the engine has said.
The design decision worth reviewing
No run id is threaded between the two sibling features.
RunNowFeatureandWorkflowCanvasFeatureare siblings under the editor route, so the obvious move is to lift the started run's id into a shared context. That is not what this does.The canvas already fetched the workflow's latest run to feed its available-data tree. It now polls that same one through the existing
useRunPolling, which stops of its own accord at a terminal status. Starting a run invalidates the run list, so the new run becomes the latest and the canvas picks it up — with nothing wired between the two components and no new state to keep consistent.Per the project's Feature/UI split, no hook or fetch enters a
ui/component: the polling lives in the feature, and the canvas receives aMap<string, string>as a prop.Why polling and not push
The run engine emits no realtime event — none of its
#[transactional]methods listsevents, so there is nothing for the gateway to forward. Making the engine publish per-step progress is a backend change of its own. Worth doing before this feature is asked to scale past one editor tab; deliberately not smuggled in here.Verification
pnpm checkpnpm vitest run src/pages/automation/pnpm exec tsc --noEmitmain's baselinepnpm buildThe border test was verified non-hollow: removing the
runBorderclass fromConnectorNodemakes it fail. Its companion — "leaves a pending connector unmarked" — passes either way by construction, since it asserts an absence; it is kept as a guard againstpendingstarting to colour later, not as evidence of this change.Historique d'exécutionstill navigates; only the post-start jump is gone, and the test that pinned that jump was rewritten to pin the opposite rather than deleted.Closes #532