fix(scorecard): status icon rendering issue in cluster env

[Eswaraiahsapram]

Hey, I just made a Pull Request!

Fix: https://redhat.atlassian.net/browse/RHDHBUGS-2996

Issue:
While testing the Scorecard plugin in the cluster environment, status icons are not rendering correctly. The same functionality works as expected in the local development environment.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Unsound icon map typing 🐞 Bug ⚙ Maintainability

Description

builtInIcons is typed as Record<string, SvgIconComponent>, which claims *every* string key
exists, but ScorecardIconProps.icon accepts arbitrary strings and builtInIcons[icon] can be
undefined at runtime. This weakens type safety around the fallback behavior and can let
missing/typoed icon keys slip through without compiler help.

Code

workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx[R26-30]

+const builtInIcons: Record<string, SvgIconComponent> = {
+  scorecardSuccessStatusIcon: CheckCircleOutline,
+  scorecardWarningStatusIcon: WarningAmber,
+  scorecardErrorStatusIcon: DangerousOutlined,
+};

Relevance

⭐⭐⭐ High

Unsound typing: Record<string,…> claims any key exists, but icon is arbitrary string and lookup may
be undefined.

PR-#2641

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

ScorecardIconProps.icon is an unconstrained string, so callers can pass values beyond the three
built-in keys; however, Record<string, SvgIconComponent> tells TypeScript that
builtInIcons[icon] always returns a component, which is not true at runtime for unknown keys.

workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx[26-30]
workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx[35-38]
workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx[54-55]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`builtInIcons` is declared as `Record<string, SvgIconComponent>`, which incorrectly promises that every string key maps to an icon. Since `icon` is an arbitrary string, indexing can return `undefined` at runtime, but the type hides that possibility.

### Issue Context
This component intentionally supports many icon formats (system icon key, MUI ligature string, URL, data URI, inline SVG). The built-in fallback should therefore be typed as a *partial* mapping.

### Fix Focus Areas
- workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx[19-30]
- workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx[54-55]

### Suggested change
- Change the type to `Partial<Record<string, SvgIconComponent>>` (or `Record<string, SvgIconComponent | undefined>`), e.g.:
 - `const builtInIcons: Partial<Record<string, SvgIconComponent>> = { ... }`
- Optionally split lookup for clarity:
 - `const builtInIcon = builtInIcons[icon];`
 - `const SystemIcon = app.getSystemIcon(icon) ?? builtInIcon;`
This keeps runtime behavior identical but makes the type contract accurate.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-scorecard	workspaces/scorecard/plugins/scorecard	patch	v2.5.1

[rhdh-qodo-merge]

Review Summary by Qodo

Fix status icon rendering in cluster environment with fallback icons

🐞 Bug fix 🧪 Tests

Walkthroughs

Description

• Add fallback to built-in Material Design icons when system icons unavailable
• Implement icon priority: system icon > built-in icon > URL/ligature fallback
• Add comprehensive test coverage for all icon rendering scenarios
• Create changeset documenting the cluster environment fix

Diagram

flowchart LR
  A["Icon Request"] --> B{"System Icon<br/>Registered?"}
  B -->|Yes| C["Use System Icon"]
  B -->|No| D{"Built-in Icon<br/>Available?"}
  D -->|Yes| E["Use Built-in Icon"]
  D -->|No| F["Fallback to URL<br/>or Ligature"]
  C --> G["Render Icon"]
  E --> G
  F --> G

Loading

File Changes

1. workspaces/scorecard/.changeset/many-frogs-count.md 📝 Documentation +5/-0

Add changeset for scorecard icon fix

• Create new changeset file documenting the patch version bump
• Document the status icon rendering fix for cluster environment

workspaces/scorecard/.changeset/many-frogs-count.md

---

2. workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx 🐞 Bug fix +12/-1

Add built-in icon fallback mechanism

• Import SvgIconComponent type and three Material Design icons (CheckCircleOutline, WarningAmber,
 DangerousOutlined)
• Create builtInIcons map providing fallback icons for scorecard status states
• Modify icon resolution logic to use nullish coalescing operator to fallback to built-in icons when
 system icon unavailable

workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/ScorecardIcon.tsx

---

3. workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/__tests__/ScorecardIcon.test.tsx 🧪 Tests +132/-0

Add comprehensive ScorecardIcon component tests

• Add 7 comprehensive test cases covering empty icon, system icon priority, built-in icon fallbacks
 for all three status types
• Test system icon preference over built-in icons
• Test URL-based icon rendering and Material Design ligature fallback
• Mock useApp hook and getSystemIcon method for isolated testing

workspaces/scorecard/plugins/scorecard/src/components/ScorecardIcon/tests/ScorecardIcon.test.tsx

---

[dzemanov]

Thank you for this quick fix! I have only 1 small comment.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dzemanov]

LGTM!