OCPBUGS-63390: show DASH to routing labels column when receiver doesn't have routing labels

[vikram-raj]

Before:

After:

[openshift-ci-robot]

@vikram-raj: This pull request references Jira Issue OCPBUGS-63390, which is invalid:

• expected the bug to target the "4.21.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Before:

After:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Walkthrough

Modified alertmanager configuration component to import a DASH constant and updated the RoutingLabels rendering logic to display DASH as a placeholder for falsy label values instead of rendering empty PfLabel components.

Changes

Cohort / File(s)	Change Summary
Alertmanager config rendering frontend/public/components/monitoring/alertmanager/alertmanager-config.tsx	Added DASH import from UI constants and modified RoutingLabels component logic to conditionally render PfLabel for truthy values and DASH placeholder for falsy entries

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Verify the DASH constant is correctly imported and semantically appropriate for displaying missing label values
• Confirm the truthy/falsy condition properly handles all value types (null, undefined, empty strings, etc.) as intended
• Validate that the visual output with DASH placeholders matches the expected UI design for empty or missing routing labels

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 370e6b0 and f4e7717.

📒 Files selected for processing (1)

• frontend/public/components/monitoring/alertmanager/alertmanager-config.tsx (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

• frontend/public/components/monitoring/alertmanager/alertmanager-config.tsx

🔇 Additional comments (2)

frontend/public/components/monitoring/alertmanager/alertmanager-config.tsx (2)

55-55: DASH import usage looks correct

Importing DASH from @console/shared/src/constants/ui is consistent with existing console patterns and keeps the placeholder centralized; no issues here.

---

229-238: RoutingLabels change likely doesn't address "no routing labels" case and could be simplified

This update only affects cases where values contains one or more falsy entries; it does not change behavior when there are no routing labels at all:

• When values.length === 0, RoutingLabels still returns null.
• When a receiver has no routing labels (receiverRoutingLabels is empty), the cell in getReceiverDataViewRows remains an empty array, so the column still renders blank.

If OCPBUGS-63390 is about showing DASH when a receiver has no routing labels, this code will not fix that scenario. Consider handling the fallback at the cell level, for example:

@@ -377,10 +377,14 @@
       [tableColumnInfo[2].id]: {
-        cell: isDefaultReceiver
-          ? t('public~All (default receiver)')
-          : _.map(receiverRoutingLabels, (rte, i) => {
-              return <RoutingLabels data={rte} key={i} />;
-            }),
+        cell: isDefaultReceiver
+          ? t('public~All (default receiver)')
+          : _.isEmpty(receiverRoutingLabels)
+          ? DASH
+          : _.map(receiverRoutingLabels, (rte, i) => {
+              return <RoutingLabels data={rte} key={i} />;
+            }),

Additionally, for consistency inside PfLabelGroup, you may want to keep everything as labels and only use DASH as content, e.g.:

-      {values.map((value, i) => (value ? <PfLabel key={`label-${i}`}>{value}</PfLabel> : DASH))}
+      {values.map((value, i) => (
+        <PfLabel key={`label-${i}`}>{value || DASH}</PfLabel>
+      ))}

This keeps styling uniform and avoids mixing raw text nodes with label components.

---

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

[vikram-raj]

/jira refresh

/retest

[openshift-ci-robot]

@vikram-raj: This pull request references Jira Issue OCPBUGS-63390, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.21.0) matches configured target version for branch (4.21.0)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @yapei

Details

In response to this:

/jira refresh

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[vikram-raj]

/retest

[jgbernalp]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jgbernalp, vikram-raj

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:

• frontend/public/components/monitoring/OWNERS [jgbernalp,vikram-raj]

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

[vikram-raj]

/retest

[vikram-raj]

/verified later @yapei

[openshift-ci-robot]

@vikram-raj: This PR has been marked to be verified later by @yapei.

Details

In response to this:

/verified later @yapei

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-bot]

/jira refresh

The requirements for Jira bugs have changed (Jira issues linked to PRs on main branch need to target different OCP), recalculating validity.

[openshift-ci-robot]

@openshift-bot: This pull request references Jira Issue OCPBUGS-63390, which is invalid:

• expected the bug to target either version "4.22." or "openshift-4.22.", but it targets "4.21.0" instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

Details

In response to this:

/jira refresh

The requirements for Jira bugs have changed (Jira issues linked to PRs on main branch need to target different OCP), recalculating validity.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[vikram-raj]

/jira refresh

/label acknowledge-critical-fixes-only

[openshift-ci-robot]

@vikram-raj: This pull request references Jira Issue OCPBUGS-63390, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.22.0) matches configured target version for branch (4.22.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @yapei

Details

In response to this:

/jira refresh

/label acknowledge-critical-fixes-only

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[vikram-raj]

/retest

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 335ed77 and 2 for PR HEAD f4e7717 in total

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 336f9f8 and 1 for PR HEAD f4e7717 in total

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 4b8da82 and 0 for PR HEAD f4e7717 in total

[openshift-ci]

@vikram-raj: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[openshift-ci-robot]

@vikram-raj: Jira Issue OCPBUGS-63390: All pull requests linked via external trackers have merged:

• openshift/console#15824

This pull request has the verified-later tag and will need to be manually moved to VERIFIED after testing. Jira Issue OCPBUGS-63390 has been moved to the MODIFIED state.

Details

In response to this:

Before:

After:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-merge-robot]

Fix included in accepted release 4.22.0-0.nightly-2025-12-17-101159

[vikram-raj]

/cherry-pick release-4.21

[openshift-cherrypick-robot]

@vikram-raj: new pull request created: #15876

Details

In response to this:

/cherry-pick release-4.21

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.