Skip to content

fix(ui): render forward-referenced DAG dependencies in Graph Viewer#16295

Open
myzk-a wants to merge 1 commit into
argoproj:mainfrom
myzk-a:fix/graphviewer-dag-genre-crash
Open

fix(ui): render forward-referenced DAG dependencies in Graph Viewer#16295
myzk-a wants to merge 1 commit into
argoproj:mainfrom
myzk-a:fix/graphviewer-dag-genre-crash

Conversation

@myzk-a

@myzk-a myzk-a commented Jun 24, 2026

Copy link
Copy Markdown

Supersedes #16119

Motivation

Opening the Graph tab for a Workflow / WorkflowTemplate / ClusterWorkflowTemplate / CronWorkflow whose DAG contains a forward reference crashes the UI with:

Cannot read properties of undefined (reading 'genre')

A forward reference is a DAG task that depends on a sibling task defined later in the tasks array. Argo's controller does not require tasks to be declared in topological order, so these workflows run perfectly fine — but the Graph tab is unusable for them.

populateGraphFromWorkflow builds the graph in a single pass: for each task it creates the node and then immediately resolves that task's dependencies. When a task references a dependency that has not been created yet (forward reference, or a name that does not match a sibling task), graph.nodes.get(dependancyName) returns undefined and reading .genre on it throws.

Reproduction

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: dag-forward-reference
spec:
  entrypoint: main
  templates:
    - name: main
      dag:
        tasks:
          # deploy is declared first but depends on build (declared below) = forward reference
          - name: deploy
            depends: "build"
            template: echo
          - name: build
            template: echo
    - name: echo
      container:
        image: alpine:3.18
        command: [echo]
        args: ["hello"]

Save this template and open its Graph tab → the view crashes with reading 'genre'.

Modifications

  • In populateGraphFromWorkflow (ui/src/shared/components/editors/graph-viewer.tsx), resolve the dependency's genre from the template model (template.dag.tasks + getTaskGenre) instead of from the partially-built graph.
    • This is order-independent, so the dependency edge is created correctly even for forward references — and it matches the exact genre value that createNode stores for that task.
  • Added a regression test asserting that the forward-referenced edge (build → deploy) is created.

Why not the guard approach (#16119)?

#16119 guards the undefined lookup and returns early, which stops the crash but drops the forward-reference edge, leaving an orphan node (the dependent task has no incoming edge). Resolving the genre from the model fixes the crash and renders the edge correctly, so it is strictly better for this case.

Verification

  • cd ui && yarn jest graph-viewer → 25 passed (includes the new forward-reference edge test).
  • cd ui && yarn lint (eslint + tsc) → clean.
  • Verified the new test goes red on current main (reading 'genre' throw) and on fix(ui): guard missing DAG dependency nodes in GraphViewer #16119's guard approach (missing build → deploy edge), and green with this change.
  • Manually verified in the running UI (make start UI=true): applied the reproduction WorkflowTemplate above, opened its Graph tab. Before the fix the tab crashed with Cannot read properties of undefined (reading 'genre'); after the fix the graph renders and the build → deploy edge is drawn correctly (screenshot below).

Graph tab after the fix (the build → deploy edge is rendered):
image

Documentation

Not needed — this is a bug fix for existing behavior with no user-facing API or configuration change.

AI

Generative AI (Claude Code) was used as a pair-programming assistant to investigate the root cause, weigh fix approaches, and draft this PR description and the commit message. The code change and the test were authored and reviewed by me.

Signed-off-by: myzk-a <rorosocksxion@gmail.com>
@myzk-a myzk-a marked this pull request as ready for review June 24, 2026 22:23
@myzk-a myzk-a requested a review from a team as a code owner June 24, 2026 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant