Refactor execution status handling

[Mbeaulne]

Description

Enhanced status visualization with detailed tooltips for pipeline runs. The status bar now shows more granular execution states and provides tooltips with detailed breakdowns of task statuses. This improves visibility into pipeline execution states by displaying the actual execution statuses rather than simplified aggregates.

We’ll display the raw status coming from the server, but map it to a “pretty” label in the UI so we can localize later, if we need to:

const EXECUTION_STATUS_LABELS: Record<string, string> = {
  CANCELLED: "Cancelled",
  CANCELLING: "Cancelling",
  FAILED: "Failed",
  INVALID: "Invalid",
  PENDING: "Pending",
  QUEUED: "Queued",
  RUNNING: "Running",
  SKIPPED: "Skipped",
  SUCCEEDED: "Succeeded",
  SYSTEM_ERROR: "System error",
  UNINITIALIZED: "Uninitialized",
  WAITING: "Waiting",
  WAITING_FOR_UPSTREAM: "Waiting for upstream",
} as const satisfies Record<ContainerExecutionStatus | "WAITING", string>;

Previously we grouped several “pending-like” states together (e.g., PENDING, QUEUED, WAITING, WAITING_FOR_UPSTREAM) and displayed them all as Pending.

Now, each execution state displays its own label and its own status color. Some statuses still share the same color to indicate they’re part of the same general category/type (e.g., multiple “in progress / not started yet” states use yellow).

export const EXECUTION_STATUS_BG_COLORS: Record<string, string> = {
  SUCCEEDED: "bg-green-500",
  FAILED: "bg-red-500",
  SYSTEM_ERROR: "bg-red-700",
  INVALID: "bg-red-600",
  RUNNING: "bg-blue-500",
  PENDING: "bg-yellow-500",
  QUEUED: "bg-yellow-500",
  WAITING_FOR_UPSTREAM: "bg-slate-500",
  SKIPPED: "bg-slate-400",
  CANCELLED: "bg-gray-700",
  CANCELLING: "bg-gray-500",
  UNINITIALIZED: "bg-yellow-400",
  WAITING: "bg-yellow-500",
};

Type of Change

• Improvement
• Cleanup/Refactor

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

Here is a real example of my local env

Here is some test data (ignore the state on the left, I was just feeding fake data into the bar for the screenshots below, so it would contain all states)

states.mov (uploaded via Graphite)

Test Instructions

1. Run a pipeline with various task statuses
2. Hover over status bars in the run list and run details page
3. Verify tooltips show detailed breakdowns of execution statuses
4. Check that status indicators correctly reflect the current state of tasks

Additional Comments

This change introduces a new utility module for execution status handling and standardizes how we display and aggregate execution statuses throughout the UI.

[Mbeaulne]

• Refactor execution status handling #1579 : 2 dependent PRs (#1580 , #1598 ) 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Volv-G]

this looks like a pretty bold change, and while I like it a lot, I'm worried that the customers might misunderstand it. I suggest discussing this during the sync. Also I think this would be a good candidate for some A/B testing if only we had that.

[maxy-shpfy]

Just for consideration. I want to get opinion about an approach where we can use @apply to create semantic CSS classes for highly re-usable places.

For cases like this, we can extract complex CSS into separate CSS files to create semantical CSS classes:

@reference "tailwindcss";

.task-status-bar {
  @apply h-2 w-full overflow-hidden rounded bg-gray-200;
}

.task-status-bar-segment-hatched {
  @apply bg-blend-multiply bg-repeat;
  background-image: repeating-linear-gradient(
    135deg,
    transparent,
    transparent 6px,
    rgba(0, 0, 0, 0.5) 6px,
    rgba(0, 0, 0, 0.5) 12px
  );
  background-size: 512px 24px;
  background-position: left top;
}

So in the code we can use it like:

<InlineStack wrap="nowrap" gap="0" className="task-status-bar" />

While this specific use-case may be not the best application of the practice, but a good place to just get the discussion going.

Official Tailwind recommendation is to try to avoid "@apply" in favor of component extraction (so entire css is isolated in one component).

[maxy-shpfy]

NIT: Similar to comment above - we can convert the status-color mapping to a CSS semantic class.

[maxy-shpfy]

NIT: since STATUS_DISPLAY_ORDER is only used here, we can micro-optimize and prepare the map beforehand and not while component rendering.

[maxy-shpfy]

NIT: make naming consistent Overall -> Aggregated so the function may be getAggregatedExecutionStatusFromStats

[maxy-shpfy]

I would prefer to have a union string type to indicate possible values.

[maxy-shpfy]

I would prefer to have a union type to represent the possible status values (we have a well-defined finite number of values)

[maxy-shpfy]

I would invest some time into improving typing for status values.

Overall LGTM, tested locally - need to test more on staging.

Also as a follow-up PR I would love to have an e2e test to cover this functionality

[Mbeaulne]

Merge activity

• Jan 6, 8:54 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jan 6, 8:54 PM UTC: @Mbeaulne merged this pull request with Graphite.