fix(frontend): resolve owner references using apiVersion+kind to prevent wrong resource links

[DashratRajpurohit]

Description

Latest Changes

• Updated OwnerReference resolution to match both kind and apiVersion.
• • Added support for array-based apiVersion definitions (e.g. Ingress).
• • Added unit tests in MetadataDisplay.test.tsx.
• • Fixed a template literal bug in the console error log.

Fixes #5569

Problem

When Headlamp shows "Controlled by" in a resource's metadata panel, it resolved
the owner reference link using only the kind field. But Kubernetes allows
different API groups to use the same kind name:

Kind	apiVersion	Source
Job	batch/v1	Built-in Kubernetes
Job	batch.volcano.sh/v1alpha1	Volcano CRD
ReplicaSet	apps/v1	Built-in Kubernetes
ReplicaSet	custom.io/v1	Custom CRD

So if a Pod was owned by a Volcano Job, Headlamp would silently link to a
batch/v1 Job — the wrong resource entirely.

This is a silent correctness bug — the UI shows a clickable link that navigates
to the wrong place with no error shown to the user.

---

Root Cause

In frontend/src/components/common/Resource/MetadataDisplay.tsx, the
makeOwnerReferences function matched resources using only ownerRef.kind:

// ❌ BEFORE — only kind is checked, apiVersion is ignored
if (ownerRef.kind in ResourceClasses) {
  routeName = ResourceClasses[ownerRef.kind as keyof typeof ResourceClasses].detailsRoute;
  // ^ picks batch/v1 Job even when the actual owner is a volcano.sh Job
}

The KubeOwnerReference type already has an apiVersion field that
uniquely identifies the API group — it was simply never used in the lookup.

Additionally, a minor pre-existing bug was found in the same function:
the console.error call used {ownerRef.kind} (a plain object literal syntax)
instead of ${ownerRef.kind} (a template literal), so error messages were
never correctly interpolated.

---

Fix

// ✅ AFTER — both kind AND apiVersion must match
const matchingClass =
  ownerRef.kind in ResourceClasses
    ? (() => {
        const cls = ResourceClasses[ownerRef.kind as keyof typeof ResourceClasses];
        // Only return the class if the apiVersion also matches the owner reference
        return cls.apiVersion === ownerRef.apiVersion ? cls : null;
      })()
    : null;

if (matchingClass) {
  routeName = matchingClass.detailsRoute; // now guaranteed to be the correct class
}

If the apiVersion does not match (e.g. a CRD with the same kind name as a
built-in resource), the owner reference is rendered as plain text instead of
an incorrect clickable link.

---

Changes

File	Description
frontend/src/components/common/Resource/MetadataDisplay.tsx	Narrow owner reference lookup to require both kind and apiVersion to match; fix template literal in console.error

Diff size: 1 file · +14 insertions · −3 deletions

---

Test Scenarios

✅ Case 1 — Standard built-in resource (link still works correctly)

# Pod owned by a standard built-in Kubernetes Job
ownerReferences:
  - apiVersion: batch/v1        # matches Job.apiVersion in ResourceClasses ✅
    kind: Job
    name: my-batch-job
    uid: abc-123

Before fix: Clickable link → correct batch/v1 Job ✅
After fix: Clickable link → correct batch/v1 Job ✅ (no regression)

---

✅ Case 2 — CRD with the same kind name (wrong link is now prevented)

# Pod owned by a Volcano CRD Job (NOT a built-in batch/v1 Job)
ownerReferences:
  - apiVersion: batch.volcano.sh/v1alpha1   # does NOT match Job.apiVersion ❌
    kind: Job
    name: my-volcano-job
    uid: def-456

Before fix: Broken link → navigates to batch/v1 Job named my-volcano-job
which likely does not exist ❌
After fix: Plain text Job: my-volcano-job — no incorrect link ✅

---

✅ Case 3 — Completely unknown CRD (unchanged behaviour)

# Resource owned by an unrecognised CRD
ownerReferences:
  - apiVersion: custom.example.com/v1
    kind: FooController
    name: foo-ctrl
    uid: ghi-789

Before fix: Plain text FooController: foo-ctrl ✅
After fix: Plain text FooController: foo-ctrl ✅ (no change)

---

✅ Case 4 — console.error template literal fix

// Before (bug): prints the literal string "{ownerRef.kind}" — not the value
console.error(`Error getting routeName for {ownerRef.kind}`, e);

// After (fixed): correctly prints the actual kind value
console.error(`Error getting routeName for ${ownerRef.kind}`, e);

---

How to Test Manually

1. Install a CRD on your cluster that uses a kind name identical to a built-in
   resource (e.g. kind: Job with apiVersion: batch.volcano.sh/v1alpha1)
2. Create a workload whose ownerReferences points to that CRD resource
3. Open Headlamp and navigate to the owned resource's detail page
4. Observe the "Controlled by" row in the metadata panel:
   • Before fix: Shows a clickable link to the wrong batch/v1 Job
   • After fix: Shows plain text since the apiVersion does not match

---

Checklist

• Linked to issue Resource: Owner references can link to the wrong resource when kinds overlap #5569
• Only 1 file modified (MetadataDisplay.tsx)
• npm run lint passes — exit code 0
• No breaking changes — built-in resources continue to produce correct links
• Backward compatible with all existing ownerReferences rendering behaviour
• Inline comment added explaining the fix with a link to the issue
• Bonus bug fixed: console.error template literal interpolation

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: DashratRajpurohit / name: DashratRajpurohit (526c568)

[k8s-ci-robot]

Welcome @DashratRajpurohit!

It looks like this is your first PR to kubernetes-sigs/headlamp 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/headlamp has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: DashratRajpurohit
Once this PR has been reviewed and has the lgtm label, please assign yolossn 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:

• OWNERS

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

[illume]

Thanks for these changes.

Can you please have a look at the git commits to see if they meet the contribution guidelines? We use a Linux kernel style of git commits. See the contributing guide for general context, and please see previous git commits with git log for examples.

Commits that need attention

• fix(frontend): resolve owner references using apiVersion+kind — Missing area: description prefix — e.g. frontend: HomeButton: Fix so it navigates to home or backend: config: Add enable-dynamic-clusters flag.

Commit guidelines

• Use atomic commits focused on a single change.
• Use the title format <area>: <Description of changes> — description must start with a capital letter.
• Keep the title under 72 characters (soft requirement).
• Explain the intention and why the change is needed.
• Make commit titles meaningful and describe what changed.
• Do not add code that a later commit rewrites; squash or reorder commits instead.
• Do not include Fixes #NN in commit messages.

Good examples:

• frontend: HomeButton: Fix so it navigates to home
• backend: config: Add enable-dynamic-clusters flag

[Copilot]

Pull request overview

This PR updates resource metadata owner-reference rendering so Headlamp only links known resources when the owner reference matches both kind and apiVersion, avoiding incorrect links for CRDs that reuse built-in kind names.

Changes:

• Adds apiVersion validation before creating owner-reference links.
• Falls back to plain text for unmatched owner references.
• Fixes the console.error interpolation for owner-reference route lookup errors.

CI status and PR commit history were not available in this review context; please confirm checks are passing and the PR history is linear.

[illume]

Thanks for the contribution.

There are some open Copilot review comments — could you take a look at them? Please mark each one as resolved once you've addressed it.

[k8s-ci-robot]

Invalid commit message issues detected

Invalid commit messages

Keywords which can automatically close issues and hashtag(#) mentions are not allowed.

• 9241636 fix(frontend): resolve owner references using apiVersion and kind

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.

[DashratRajpurohit]

@illume all feedback has been addressed with the latest changes and unit tests. I have updated the PR description with the summary of changes.