Fix Deploy UI showing Failed for ProjectReleaseBinding during namespace provisioning

[ChaninduImanjith]

Purpose

Resolves openchoreo/openchoreo#4440

Goals

Fix the Deploy UI incorrectly showing "Failed" for a ProjectReleaseBinding while its DataPlane Namespace is still being provisioned (normal NamespaceProgressing state).

Approach

Added NamespaceProgressing to the PROGRESSING_REASONS list in deriveBindingStatusDetailed (release-binding.ts). This reason is set by the core controller when the Project's DataPlane Namespace is still being created or has not yet been observed as ready — it was previously falling through to the default "Failed" status branch since it wasn't recognized as a progressing state.

User stories

As a developer deploying a Project for the first time, I want the Deploy UI to show a "Pending" or in-progress status while the namespace is provisioning, instead of a misleading "Failed" status that later flips to "Active" without any retry.

Release note

Fixed an issue where the Deploy UI showed "Failed" for a ProjectReleaseBinding during normal namespace-provisioning, before it became "Active".

Documentation

N/A - Bug fix, no doc impact.

Training

N/A

Certification

N/A - No impact on certification exams.

Marketing

N/A

Automation tests

Added a unit test for the NamespaceProgressing reason in release-binding.test.ts to verify it derives a NotReady status instead of Failed.

Security checks

• Followed secure coding standards? Yes
• Ran FindSecurityBugs plugin? N/A
• No keys, passwords, or secrets committed? Yes

Samples

N/A

Related PRs

N/A

Migrations

N/A

Test environment

Verified the logic change against the reported reproduction steps in openchoreo/openchoreo#4440.

Learning

Traced the status derivation logic from the reported UI symptom back to deriveBindingStatusDetailed in release-binding.ts, where NamespaceProgressing was missing from the PROGRESSING_REASONS allow-list.

Summary by CodeRabbit

• Bug Fixes
  • Bindings now remain in a pending state while their namespace is progressing, instead of being incorrectly marked as failed.

[github-actions]

Changeset detected — the following file(s) will be released with this PR:

.changeset/upset-clowns-worry.md

[coderabbitai]

📝 Walkthrough

Walkthrough

The release-binding transformer now treats NamespaceProgressing as a transient progressing condition. Bindings remain NotReady during namespace provisioning instead of being classified as failures.

Changes

Release-binding status transformation

Layer / File(s)	Summary
Classify namespace provisioning as progressing plugins/openchoreo-backend/src/services/transformers/release-binding.ts	Adds NamespaceProgressing to PROGRESSING_REASONS, so namespace provisioning remains a transient NotReady state.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related issues

• openchoreo/backstage-plugins issue 745 — Addresses NamespaceProgressing handling in the release-binding status transformation.

Suggested reviewers: kaviththiranga

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The change directly resolves issue #4440 by treating NamespaceProgressing as an in-progress binding state.
Out of Scope Changes check	✅ Passed	The change is limited to the status transformation required for namespace provisioning and contains no unrelated modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title clearly identifies the Deploy UI bug and the affected ProjectReleaseBinding during namespace provisioning.
Description check	✅ Passed	The description covers the required sections and clearly explains the issue, solution, testing, release note, and impacts.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 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.}

[Copilot]

Pull request overview

Updates OpenChoreo backend status-derivation logic so the Deploy UI treats NamespaceProgressing as an in-progress (pending) state for ProjectReleaseBinding while the DataPlane namespace is provisioning, instead of incorrectly showing it as Failed.

Changes:

• Added NamespaceProgressing to the PROGRESSING_REASONS allow-list used by deriveBindingStatusDetailed.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

🧹 Nitpick comments (1)

plugins/openchoreo-backend/src/services/transformers/release-binding.ts (1)

22-24: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add focused regression coverage for NamespaceProgressing.

The supplied test context covers ResourcesProgressing, but it does not show a case for this new reason. Add or verify a test that sends Ready=False with reason NamespaceProgressing and expects NotReady.

🤖 Prompt for 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.

In `@plugins/openchoreo-backend/src/services/transformers/release-binding.ts`
around lines 22 - 24, Add focused regression coverage for the release-binding
readiness transformer covering a Ready=False condition with reason
NamespaceProgressing, and assert that it produces NotReady rather than an error
state. Reuse the existing ResourcesProgressing test setup and extend the
relevant transformer test without changing unrelated readiness behavior.

🤖 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.

Nitpick comments:
In `@plugins/openchoreo-backend/src/services/transformers/release-binding.ts`:
- Around line 22-24: Add focused regression coverage for the release-binding
readiness transformer covering a Ready=False condition with reason
NamespaceProgressing, and assert that it produces NotReady rather than an error
state. Reuse the existing ResourcesProgressing test setup and extend the
relevant transformer test without changing unrelated readiness behavior.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e8146344-f92a-4cef-b074-6ed773a91569

📥 Commits

Reviewing files that changed from the base of the PR and between 6729dc3 and b1e7667.

📒 Files selected for processing (1)

• plugins/openchoreo-backend/src/services/transformers/release-binding.ts

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

plugins/openchoreo-backend/src/services/transformers/release-binding.test.ts:63

• PR description states "No new tests added" under Automation tests, but this PR introduces a new unit test covering the NamespaceProgressing reason. Please update the PR description to reflect that a test was added (or adjust the claim accordingly) to avoid confusion for reviewers and release notes automation.

  it('returns NotReady for NamespaceProgressing reason', () => {
    const binding = makeBinding([
      {
        type: 'Ready',
        status: 'False',

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[kaviththiranga]

Thank you for your contribution @ChaninduImanjith. LGTM and I will merge this.

However, as I have explained in #743 (comment), we need to change the approach here to handle any new pending-states which will introduced in future.

We will send in a follow up PR for that.

[ChaninduImanjith]

Thank you for your contribution @ChaninduImanjith. LGTM and I will merge this.

However, as I have explained in #743 (comment), we need to change the approach here to handle any new pending-states which will introduced in future.

We will send in a follow up PR for that.

Thank you @kaviththiranga for reviewing and merging this! I understand the concern about the allow-list approach — happy to contribute to the follow-up refactor if that would be helpful.