fix: map WorkflowRun UI status from WorkflowCompleted reasons

[artemiyokulov]

Summary

• Add shared deriveWorkflowRunDisplayStatus that understands both typed conditions (WorkflowFailed / WorkflowSucceeded) and aggregate WorkflowCompleted=True + reason (WorkflowFailed, ComponentValidationFailed, WorkflowSucceeded, …).
• Use it from Workflows backend, CI backend, and transformComponentWorkflowRun so completed failures no longer show as Pending (or false Succeeded when tasks[] lag).

Fixes openchoreo/openchoreo#4442
Related: openchoreo/openchoreo#4419
Related controller fix class: openchoreo/openchoreo#3877

Context

On some terminal failure paths the WorkflowRun CR has:

• completedAt set
• WorkflowCompleted=True reason=WorkflowFailed
• no typed WorkflowFailed=True
• stale tasks[].phase: Pending

GenericWorkflowService.deriveWorkflowRunStatus previously only checked typed conditions → default Pending. CI/completedAt paths could even report Succeeded when tasks were not Failed.

Test plan

• Unit tests for deriveWorkflowRunDisplayStatus (workflowRunStatus.test.ts)
• Transformer test for WorkflowCompleted + stale Pending task → Failed
• Manual: failed WorkflowRun with only WorkflowCompleted/WorkflowFailed → Workflows + CI chips show Failed
• Manual: succeeded run with WorkflowCompleted/WorkflowSucceeded still shows Succeeded
• Manual: running run with WorkflowRunning=True still shows Running

Made with Cursor

Summary by CodeRabbit

• Bug Fixes

  • Improved WorkflowRun status display across workflow views for completed, failed, succeeded, running, and pending workflows.
  • Failed runs now consistently appear as Failed, rather than showing an underlying failure reason.
  • Completed workflows are correctly prioritized over stale task statuses and accurately reflect completion outcomes.
  • Status handling is now consistent across all workflow views.

• Tests

  • Added comprehensive coverage for workflow status mapping, completion details, pending tasks, and edge cases.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5d34ba87-cd23-42d6-9a6a-946074fbe1b9

📥 Commits

Reviewing files that changed from the base of the PR and between a1acf73 and 729d750.

📒 Files selected for processing (2)

• plugins/openchoreo-common/src/workflowRunStatus.test.ts
• plugins/openchoreo-common/src/workflowRunStatus.ts

---

📝 Walkthrough

Walkthrough

The PR adds shared WorkflowRun display-status derivation, exports it with related types, and replaces local status logic in three backend paths. Tests cover completed failures and other condition, task, and timestamp combinations. A changeset records patch releases for four packages.

Changes

WorkflowRun status handling

Layer / File(s)	Summary
Shared status derivation contract and logic plugins/openchoreo-common/src/workflowRunStatus.ts, plugins/openchoreo-common/src/workflowRunStatus.test.ts, plugins/openchoreo-common/src/index.ts	Adds typed WorkflowRun status inputs. Derives Pending, Running, Succeeded, Failed, or Completed from conditions, reasons, timestamps, and task phases. Exports the helper and related types.
Backend status integration and release coverage plugins/openchoreo-workflows-backend/..., plugins/openchoreo-ci-backend/..., plugins/openchoreo-backend/src/services/transformers/*, .changeset/workflowrun-completed-status.md	Routes three backend status transformations through the shared helper. Adds coverage for completed failed runs, adds the common workspace dependency, and records patch releases for four packages.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GenericWorkflowService
  participant WorkflowService
  participant WorkflowRunTransformer
  participant deriveWorkflowRunDisplayStatus
  GenericWorkflowService->>deriveWorkflowRunDisplayStatus: pass WorkflowRun status data
  WorkflowService->>deriveWorkflowRunDisplayStatus: pass WorkflowRun status data
  WorkflowRunTransformer->>deriveWorkflowRunDisplayStatus: pass WorkflowRun status data
  deriveWorkflowRunDisplayStatus-->>GenericWorkflowService: return display status
  deriveWorkflowRunDisplayStatus-->>WorkflowService: return display status
  deriveWorkflowRunDisplayStatus-->>WorkflowRunTransformer: return display status

Loading

Possibly related issues

• openchoreo/backstage-plugins#740: Centralizes status derivation to recognize WorkflowCompleted failure reasons.
• openchoreo/openchoreo#4442: Covers completed WorkflowRuns that display as Pending when only aggregate failure conditions exist.
• openchoreo/openchoreo#4419: Covers recognition of WorkflowCompleted with reason: WorkflowFailed without a typed WorkflowFailed condition.

Suggested reviewers: kaviththiranga

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description explains the fix and tests, but it omits many required template sections, including release notes, documentation, security checks, and test environment.	Complete the required template sections, or mark non-applicable sections as N/A with brief explanations.
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: mapping WorkflowRun UI status from WorkflowCompleted reasons.
Linked Issues check	✅ Passed	The shared status logic satisfies issue #4442 by mapping completed failure reasons to Failed and preserving typed success and failure handling.
Out of Scope Changes check	✅ Passed	The changes are limited to shared WorkflowRun status logic, related backend integrations, exports, tests, dependency wiring, and the associated changeset.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@plugins/openchoreo-common/src/workflowRunStatus.ts`:
- Around line 93-100: Update the terminal-reason handling in
workflowRunStatus.ts so unrecognized terminal reasons return the documented
Completed display status instead of the raw reason, while preserving recognized
statuses and useful specific labels. Add a test covering an unrecognized
terminal reason such as Cancelled and assert it normalizes to Completed.
- Around line 76-101: Update the condition evaluation in the workflow status
resolver so a `WorkflowCompleted=True` condition with an
`isFailureReason(reason)` result is handled before the `WorkflowSucceeded=True`
check, preserving failure precedence. Keep existing success and terminal-reason
behavior unchanged, and add a test covering both conditions where the result
must be `Failed`.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: a08e3762-e2a1-4538-a34f-4b15497da375

📥 Commits

Reviewing files that changed from the base of the PR and between 9eb3d31 and 539f105.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (9)

• .changeset/workflowrun-completed-status.md
• plugins/openchoreo-backend/src/services/transformers/transformers.test.ts
• plugins/openchoreo-backend/src/services/transformers/workflow-run.ts
• plugins/openchoreo-ci-backend/src/services/WorkflowService.ts
• plugins/openchoreo-common/src/index.ts
• plugins/openchoreo-common/src/workflowRunStatus.test.ts
• plugins/openchoreo-common/src/workflowRunStatus.ts
• plugins/openchoreo-workflows-backend/package.json
• plugins/openchoreo-workflows-backend/src/services/GenericWorkflowService.ts

[artemiyokulov]

Addressed CI/review feedback:

1. DCO — rewrote commit with Signed-off-by
2. CodeRabbit — WorkflowCompleted failure now takes precedence over typed WorkflowSucceeded; unrecognized terminal reasons normalize to Completed (with tests)

[coderabbitai]

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

[artemiyokulov]

CI follow-up:

1. Lint — Prettier on workflowRunStatus.test.ts (fixed in latest commit).
2. Tests — failure is unrelated flaky useOpenChoreoCache › invalidate marks a cached prefix stale and refetches it (Expected: "first", Received: undefined). Not touched by this PR; our workflowRunStatus suite is green.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[kaviththiranga]

@artemiyokulov Thank you for the contribution.

It seems that some of the files you touch are leftover code from multiple ci/workflows related rewrites. But removing those can be a different task and I have raised an issue for that.

Thanks for working through this one. The direction is right: mapping WorkflowCompleted reasons to
a real status fixes runs that used to sit on "Pending" forever, and treating a completion failure as
more important than a typed success is the correct call. Coverage looks good too.

One thing to fix before I approve.

This helper is supposed to return one of five values: Pending, Running, Succeeded, Failed,
or Completed. Most of it does. But in two places it returns the condition's reason string
directly, so something like Progressing or DeadlineExceeded can come out instead.

That causes real problems downstream. The workflows backend takes whatever this returns and checks
it against an exact list of finished statuses to decide whether to go fetch the logs. A value that
isn't on that list means the logs never load — the user just sees an empty log panel with no error.
The status chip has the same issue: anything it doesn't recognize gets styled as if the run were
still pending, so a finished run looks stuck.

Line 132 — the run has a completedAt, so it's definitely finished. Return Completed instead
of the raw reason:

      return isFailureReason(reason) ? 'Failed' : 'Completed';

Lines 137-143 — here there's no completedAt, so the run isn't finished yet. The existing
check on line 143 already gives the right answer, and the reason only needs to be looked at for
failures. The whole block can collapse to:

  if (readyCondition) {
    if (isFailureReason(readyCondition.reason)) return 'Failed';
    return readyCondition.status === 'True' ? 'Succeeded' : 'Running';
  }

To be clear, neither of these is breaking anything today — the WorkflowRun controller doesn't set a
Ready condition at all right now, so those branches aren't being hit. But the whole point of
moving this into a shared helper is that two backends can rely on what it returns, so I'd rather it
be airtight before it has multiple consumers.

Two smaller things, neither blocking:

• Line 92 — a typed WorkflowSucceeded now wins before the failed-task check further down on
  line 122. The old CI backend checked failed tasks first. Given you already made completion
  failures take priority, this only matters if the controller reports contradictory state, so I'm
  fine leaving it — just want to make sure it's intentional rather than a side effect of the
  reordering.
• Line 114 — the WorkloadUpdated branch can't run. That condition was removed from the
  controller in feat: create workload through api server openchoreo#2469.

One last note: chips will now show Failed where they used to show BuildFailed or
ComponentValidationFailed. That's correct for a fixed set of statuses, but we lose some useful
detail in the UI. We can address it separately.