OCPBUGS-85013: Fix Topology page TypeError when resource is null

[platex-rehor-bot]

Analysis / Root cause:

The Topology view crashes with TypeError: can't access property kind, e is null when rendering nodes whose resource object has not yet loaded or is unavailable. This occurs when installing Helm charts from the Developer Catalog — the Helm release group node may not have a matching Secret, causing getTopologyResourceObject() to return null. Several topology components then pass this null to referenceFor(), which destructures { kind, apiVersion } from its argument, producing the TypeError.

The root cause is in helm-data-transformer.ts line 89 where resources.obj is explicitly set to null when no matching Secret exists:

obj: secret ? { ...secret, kind, apiVersion } : null,

Multiple downstream consumers (WorkloadNode, BaseNode, BindableNode, withEditReviewAccess, OdcBaseNode, getResourceKind) access .kind or call referenceFor() on the result without null guards.

Solution description:

Added null guards using optional chaining (?.) and conditional expressions across all affected call sites in the topology package:

• WorkloadNode.tsx: resource?.kind and resource?.metadata?.namespace instead of direct access
• BaseNode.tsx: Guard referenceFor(resourceObj) and resourceObj.metadata.* with null checks
• BindableNode.tsx: Guard referenceFor(resourceObj) with null check
• withEditReviewAccess.tsx: Guard referenceFor(resourceObj), resourceModel.*, and resourceObj.metadata.*
• OdcBaseNode.ts: Guard referenceFor(this.resource) when resource is undefined
• topology-utils.ts: Guard referenceFor() result in getResourceKind utility

All changes are minimal defensive additions — no logic changes, no new behavior when resources are present.

Screenshots / screen recording:

Test setup:
Install a Helm chart from the Developer Catalog (e.g. Edge Manager) and navigate to the Topology view while resources are still initializing.

Test cases:

• Install a Helm chart from Developer Catalog → Topology view renders without crash
• Navigate to Topology view with existing Helm releases → nodes render correctly
• Topology view for non-Helm workloads still works correctly
• Collapsed and expanded Helm release group nodes render without error

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:
Jira: https://redhat.atlassian.net/browse/OCPBUGS-85013

Reviewers and assignees:

Summary by CodeRabbit

• Bug Fixes
  • Improved topology views to handle missing or incomplete resource information safely.
  • Prevented errors when resource metadata, kinds, namespaces, or models are unavailable.
  • Improved access review handling when resource details are incomplete.

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[openshift-ci-robot]

@platex-rehor-bot: This pull request references Jira Issue OCPBUGS-85013, which is invalid:

• expected the bug to target the "5.1.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:

Analysis / Root cause:

The Topology view crashes with TypeError: can't access property kind, e is null when rendering nodes whose resource object has not yet loaded or is unavailable. This occurs when installing Helm charts from the Developer Catalog — the Helm release group node may not have a matching Secret, causing getTopologyResourceObject() to return null. Several topology components then pass this null to referenceFor(), which destructures { kind, apiVersion } from its argument, producing the TypeError.

The root cause is in helm-data-transformer.ts line 89 where resources.obj is explicitly set to null when no matching Secret exists:

obj: secret ? { ...secret, kind, apiVersion } : null,

Multiple downstream consumers (WorkloadNode, BaseNode, BindableNode, withEditReviewAccess, OdcBaseNode, getResourceKind) access .kind or call referenceFor() on the result without null guards.

Solution description:

Added null guards using optional chaining (?.) and conditional expressions across all affected call sites in the topology package:

• WorkloadNode.tsx: resource?.kind and resource?.metadata?.namespace instead of direct access
• BaseNode.tsx: Guard referenceFor(resourceObj) and resourceObj.metadata.* with null checks
• BindableNode.tsx: Guard referenceFor(resourceObj) with null check
• withEditReviewAccess.tsx: Guard referenceFor(resourceObj), resourceModel.*, and resourceObj.metadata.*
• OdcBaseNode.ts: Guard referenceFor(this.resource) when resource is undefined
• topology-utils.ts: Guard referenceFor() result in getResourceKind utility

All changes are minimal defensive additions — no logic changes, no new behavior when resources are present.

Screenshots / screen recording:

Test setup:
Install a Helm chart from the Developer Catalog (e.g. Edge Manager) and navigate to the Topology view while resources are still initializing.

Test cases:

• Install a Helm chart from Developer Catalog → Topology view renders without crash
• Navigate to Topology view with existing Helm releases → nodes render correctly
• Topology view for non-Helm workloads still works correctly
• Collapsed and expanded Helm release group nodes render without error

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:
Jira: https://redhat.atlassian.net/browse/OCPBUGS-85013

Reviewers and assignees:

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]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: f8935a5e-8177-4145-abbe-4e70237831ff

📥 Commits

Reviewing files that changed from the base of the PR and between 9d6a5b0 and 55f7fc2.

📒 Files selected for processing (6)

• frontend/packages/topology/src/components/graph-view/components/nodes/BaseNode.tsx
• frontend/packages/topology/src/components/graph-view/components/nodes/BindableNode.tsx
• frontend/packages/topology/src/components/graph-view/components/nodes/WorkloadNode.tsx
• frontend/packages/topology/src/elements/OdcBaseNode.ts
• frontend/packages/topology/src/utils/topology-utils.ts
• frontend/packages/topology/src/utils/withEditReviewAccess.tsx

Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review.

---

Walkthrough

Topology resource resolution now handles missing resources and metadata without throwing. Graph nodes pass optional values to model lookup, access review, resource-kind resolution, and pod watching.

Changes

Topology resource safety

Layer / File(s)	Summary
Guard shared resource resolution frontend/packages/topology/src/elements/OdcBaseNode.ts, frontend/packages/topology/src/utils/topology-utils.ts, frontend/packages/topology/src/utils/withEditReviewAccess.tsx	Resource kind and access-review resolution now avoid dereferencing absent resources or models.
Apply guards in graph nodes frontend/packages/topology/src/components/graph-view/components/nodes/BaseNode.tsx, frontend/packages/topology/src/components/graph-view/components/nodes/BindableNode.tsx, frontend/packages/topology/src/components/graph-view/components/nodes/WorkloadNode.tsx	Graph nodes use conditional model lookup and optional resource metadata when resources are missing or incomplete.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 55f7f

This PR adds localized null handling to prevent Topology crashes when resources are unavailable; no actionable merge-blocking risk remains after normal checks and review.

Suggested reviewers: logonoff

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the Jira issue and accurately summarizes the Topology null-resource crash fix.
Description check	✅ Passed	The description covers the root cause, solution, testing setup, test cases, browser checklist, and additional issue information.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 6 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	The PR changes only six frontend source files; the diff adds no test files or Ginkgo It, Describe, Context, or When titles.
Test Structure And Quality	✅ Passed	The PR changes only six frontend TypeScript files. No Ginkgo test files, It blocks, cluster operations, or Eventually/Consistently calls changed, so these requirements are not applicable.
Microshift Test Compatibility	✅ Passed	The PR changes only six frontend TypeScript files; the diff adds no Ginkgo declarations or Go test files, so MicroShift test compatibility is not applicable.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	The commit adds no Ginkgo e2e tests. It changes only six frontend topology source files, so no SNO multi-node test assumption is introduced.
Topology-Aware Scheduling Compatibility	✅ Passed	The diff modifies only six frontend topology TS/TSX files for null handling; it adds no deployment manifests, operator/controller code, or scheduling constraints.
Ote Binary Stdout Contract	✅ Passed	The commit changes only six frontend TypeScript files; no Go, OTE entrypoint, suite setup, or stdout/logging additions appear in the diff.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	The commit changes only six TypeScript source files and adds no Ginkgo e2e tests, IPv4 assumptions, or external connectivity requirements.
No-Weak-Crypto	✅ Passed	The six-file PR adds only null guards and conditional resource lookups; added lines contain no MD5, SHA1, DES, RC4, Blowfish, ECB, crypto API, or secret comparison.
Container-Privileges	✅ Passed	The PR changes only six TypeScript/TSX topology files. The complete patch adds no privileged, hostPID, hostNetwork, hostIPC, SYS_ADMIN, or allowPrivilegeEscalation settings.
No-Sensitive-Data-In-Logs	✅ Passed	The PR changes only null guards and conditional resource resolution; the six-file diff adds no logging, telemetry, or diagnostic output that could expose sensitive data.

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

[platex-rehor-bot]

/jira refresh

[openshift-ci-robot]

@platex-rehor-bot: This pull request references Jira Issue OCPBUGS-85013, which is invalid:

• expected the bug to target the "5.1.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.

Details

In response to this:

/jira refresh

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-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: platex-rehor-bot
Once this PR has been reviewed and has the lgtm label, please assign vojtechszocs for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS

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

[openshift-ci]

Hi @platex-rehor-bot. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[platex-rehor-bot]

/jira refresh

[openshift-ci-robot]

@platex-rehor-bot: This pull request references Jira Issue OCPBUGS-85013, which is valid.

3 validation(s) were run on this bug

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

No GitHub users were found matching the public email listed for the QA contact in Jira (mniranja@redhat.com), skipping review request.

Details

In response to this:

/jira refresh

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.