Skip to content

fix(breadcrumbs): link to the executed workflow, not the launch plan#921

Open
1fanwang wants to merge 1 commit into
flyteorg:masterfrom
1fanwang:fix-breadcrumb-uses-executed-workflow
Open

fix(breadcrumbs): link to the executed workflow, not the launch plan#921
1fanwang wants to merge 1 commit into
flyteorg:masterfrom
1fanwang:fix-breadcrumb-uses-executed-workflow

Conversation

@1fanwang

@1fanwang 1fanwang commented Jun 21, 2026

Copy link
Copy Markdown

TL;DR

When a launch plan is named differently from its workflow, the execution breadcrumb's link to the workflow goes nowhere — it points at the launch plan's name, which isn't a workflow, so you land on an empty page.

Type

  • Bug Fix
  • Feature
  • Plugin

Are all requirements met?

  • Code completed
  • Smoke tested
  • Unit tests added
  • Code documentation added
  • Any pending items have an associated Issue

Complete description

The breadcrumb built its link — and the name, version, and project/domain — from spec.launchPlan, the launch plan's identity, when it should follow closure.workflowId, the workflow that actually ran. The two usually share a name, which is why this went unnoticed. I read those fields from closure.workflowId instead, relabeled the crumb "Workflow Name", and fixed a neighboring projectId === …domain comparison that should have been domainId.

Smoke-tested on a live console with an execution launched through a launch plan named differently from its workflow: before, the crumb links to a workflow page that doesn't exist; after, to the real one. executionContext.test.ts covers it.

Tracking Issue

NA

Follow-up issue

NA

The execution breadcrumb's self-link, name, version, and project/domain were
read from spec.launchPlan (the launch plan identity) instead of
closure.workflowId (the workflow that actually ran). When a launch plan's name
differs from its workflow's, the breadcrumb labels and links pointed at a
non-existent workflow page.

Read them from closure.workflowId, relabel the crumb "Workflow Name", and fix
the domain resolution that compared projectId to the domain.

Signed-off-by: 1fanwang <1fannnw@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant