Uh oh!
There was an error while loading. Please reload this page.
feat(web): make sub-workflow nodes expandable before they run - #360
Merged
Conversation
Eagerly resolve a `type: workflow` agent's referenced sub-workflow file at `workflow_started` build time (`WorkflowEngine._build_static_subworkflow_topology`, recursive, best-effort) and attach its topology to the agent's entry in the `workflow_started` payload. The dashboard store seeds a `pending` placeholder child context from this static topology as soon as the workflow starts, so `WorkflowNode`'s expand chevron is now clickable (and shows the real inner DAG) from the beginning of the run instead of only after the engine actually reaches that step. `subworkflow_started` reuses the placeholder in place rather than pushing a duplicate. Adds an internal per-engine cache for `_resolve_subworkflow_path` so the eager preview and the real execution don't double up on network/registry fetches for the same sub-workflow reference within a single run. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Widen the try/except in `_build_static_subworkflow_topology` to cover the entire method body (recursive call + dict construction), not just the initial file/config resolution. Previously an unexpected exception from a malformed sub-config could escape uncaught and turn a best-effort dashboard preview into a hard failure of the whole run (and, on the resume path in cli/run.py, crash `conductor resume` entirely) — contradicting the documented "purely advisory" guarantee. - Fix `buildStaticChildContext` silently dropping nested static previews for `type: workflow` agents that belong to a parallel group two+ levels deep, by delegating to `seedStaticSubworkflowChildren` (which already handled this correctly at the root level) instead of duplicating the loop with an early `continue` that skipped parallel-group members before checking for a `subworkflow` topology. - Fix a docstring citing a non-existent `_execute_workflow_step` method; correct references to the real `_execute_subworkflow`/ `_execute_subworkflow_with_inputs`. - Replace a fake "(issue: ...)" citation with plain prose, and trim duplicated caching/resume rationale repeated across three comments. - Add test coverage: self-referencing and mutually-referencing (A->B->A) sub-workflow cycle detection, eager-path depth-limit truncation, registry-ref eager resolution sharing the memoized fetch with real execution, a loop-back re-invocation test (frontend) proving a second `subworkflow_started` pushes a new context rather than reusing a completed one, and a regression test for the parallel-group nested preview fix above. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Jason Robert (jrob5756)
marked this pull request as ready for review
August 3, 2026 20:57
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Sub-workflow (
type: workflow) nodes in the dashboard were only expandable once the engine actually reached that step (subworkflow_started). This eagerly resolves the sub-workflow's static topology up front so the node is expandable — showing the real inner DAG — from the very beginning of a run.Changes
WorkflowEngine._build_static_subworkflow_topology(new): best-effort, recursive, eager resolution of atype: workflowagent's referenced file. Safe to do eagerly becauseworkflow:is a plain string, never Jinja-templated. Any failure (missing file, registry error, cycle, depth limit) degrades gracefully toNone— the sub-workflow still resolves normally when the engine reaches it.build_workflow_started_datais nowasyncand attachessubworkflow: <topology> | nullto everytype: workflowagent entry._resolve_subworkflow_pathis now a memoizing wrapper (per engine instance) around the existing resolution logic (renamed_resolve_subworkflow_path_uncached), so eager preview + real execution don't double up on registry fetches within a single run.workflow_startedseeds apendingplaceholder childSubworkflowContextfrom the static topology (recursively, for nested sub-workflows too).subworkflow_startedreuses this placeholder in place instead of pushing a duplicate once the step actually starts.WorkflowNode.tsx: updated comments/tooltip; behavior otherwise unchanged (samecanExpandlogic, now backed by the eager preview).Testing
uv run pytest— full suite passes (4640 passed; 1 pre-existing flaky perf test passes in isolation, unrelated to this change).npm run test(frontend) — 56 passed, including new coverage for static topology seeding, recursive nested previews, gracefulnullfallback, and placeholder reuse onsubworkflow_started.npx tsc --noEmit— clean.make build-frontend— rebuiltstatic/assets.