Added edge case for re-enabling source on the MC settings page

[YuliaKrimerman]

Fix catalog source status feedback when re-enabling after disable

Description

Fixed a UI feedback issue where re-enabling a catalog source after disabling it showed "-" instead of "Starting" status, providing no feedback that the source was loading.

Root Cause:
When a catalog source is re-enabled:

• ConfigMap updates immediately: enabled: true
• Database/API response lags behind: status: DISABLED (until loading completes)
• Frontend only showed "Starting" for new sources (status=null), not for re-enabled sources (status=DISABLED)

Solution:
Updated CatalogSourceStatus.tsx to handle the ConfigMap/API mismatch. The component now shows "Starting" status when:

• ConfigMap indicates enabled: true (checked at line 24)
• AND API still returns status: DISABLED (caught in switch statement)

Code Changes:

• Leverages existing early return when enabled: false (line 24-26)
• When DISABLED case is reached in switch statement, we know enabled: true due to early return
• Simplified logic to return "Starting" label directly without redundant conditional check

User Experience:

• ✅ First time enabling: Shows "Starting" → "Available"/"Failed" (already worked)
• ✅ Re-enabling after disable: Shows "Starting" → "Available"/"Failed" (now fixed)
• ✅ Disabled source: Shows "-" (unchanged)

How Has This Been Tested?

• Manually tested the re-enable flow:
  1. Created a catalog source
  2. Disabled it (status shows "-")
  3. Re-enabled it (status now shows "Starting" instead of "-")
• Verified disabled sources still show "-"
• Verified first-time enable still shows "Starting"
• Code passes linter checks with no errors

Merge criteria:

• All the commits have been signed-off (To pass the DCO check)

• The commits have meaningful messages

• Automated tests are provided as part of the PR for major new functionalities; testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).

• The developer has manually tested the changes and verified that the changes work.

• Code changes follow the kubeflow contribution guidelines.

• For first time contributors: Please reach out to the Reviewers to ensure all tests are being run, ensuring the label ok-to-test has been added to the PR.

If you have UI changes

• The developer has added tests or explained why testing cannot be added.
  • Explanation: This is a UI timing/state synchronization fix. The existing component relies on early returns for control flow, and the fix leverages that existing logic. Manual testing confirms the fix works correctly.
• Included any necessary screenshots or gifs if it was a UI change.
• Verify that UI/UX changes conform the UX guidelines for Kubeflow.

[manaswinidas]

any cypress test that needs to be changed coz of this change - surprised no tests failed - maybe tests are missing entirely for this case 🤔

[mturley]

@YuliaKrimerman can we explore maybe adding some tests here? we could see if AI can generate a handful of cypress tests to check that we're showing the right thing in the status column for various cases of what's present in the configmap and in the API. if that takes too much of your time we could open an issue to improve testing coverage instead.

[YuliaKrimerman]

@mturley @manaswinidas the tests are there for other cases of the status updates, I added another test case that covers this scenario

[mturley]

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mturley

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• clients/ui/OWNERS [mturley]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment