frontend: src: Use kind and apiVersion for Link component routing

[dibyanshu-pal-kushwaha]

Summary

This PR fixes the incorrect routing of resources that share the same Kind name as core Kubernetes resources (but belong to different apiGroups), such as Knative Services.Currently in the codebase, any Non core service with kind Service navigates to the core Service details page instead of the dedicated Service page.So , This PR helps in correct routing.

Related Issue

Fixes #4267

Changes

1. Link component: Updated the routing logic to check both kind and apiGroupName.
   2.Collision Detection: Added a check to verify if a resource's API group matches the "standard" core group before attempting to open the right-side details drawer.
   3.Routing: Ensures that non-standard resources (like Knative Services) bypass the standard drawer and correctly navigate to their specific full-page views.

Steps to Test

1. Verify Core Resources: Navigate to Network > Services. Click on the kubernetes service.
   Expected: The right-side drawer should open normally.
2. Verify colliding CRDs (Knative): Navigate to Custom Resources > services.serving.knative.dev. Click on a Knative Service link.
   Expected: You should be redirected to the Knative Service details page. The core Service drawer should not open.

Screenshots (After Fixing)

For Core Services :

For Custom Services :
As you can see clearly , here I have created a fake Knative service to check and it is working positively , routing to the dedicated page rather than Core K8s services.

Notes for the Reviewer

• The implementation is generic and does not hardcode "Knative". It will work for any CRD that happens to reuse a core Kind name .
• This change specifically touches the Link component which is used throughout the dashboard, so it improves routing across all resource tables.

[Copilot]

Pull request overview

This PR fixes routing issues for Custom Resource Definitions (CRDs) that share the same kind name as core Kubernetes resources, such as Knative Services. The solution adds collision detection logic to distinguish between standard and non-standard resources by comparing their API groups, ensuring that only resources matching the standard API group open in the detail drawer.

Changes:

• Added collision detection in the Link component to compare API group names between custom resources and standard Kubernetes resources
• Modified the drawer opening condition to prevent non-standard resources from incorrectly opening the standard resource drawer
• Updated indentation for code consistency (with some minor formatting issues remaining)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dibyanshu-pal-kushwaha, kahirokunn
Once this PR has been reviewed and has the lgtm label, please assign joaquimrocha 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

[kahirokunn]

The matchesStandard check appears to be functioning correctly.

[kahirokunn]

Did it function properly when you actually tested it manually? 👀

[skoeva]

Hi! Would you mind addressing the copilot review comments and the linting failure in the CI?

[kahirokunn]

After reviewing the source code, it appears that the comparison is likely being made solely based on the kind without checking the apiGroup. Could you explain why this resolved the issue? 🙏

[dibyanshu-pal-kushwaha]

@kahirokunn

After reviewing the source code, it appears that the comparison is likely being made solely based on the kind without checking the apiGroup. Could you explain why this resolved the issue?

Yes sir Sorry for the late reply , I currently applied the kind and apiGroup check for correct routing. I verified this locally on Minikube by creating a collision scenario . The Link component now correctly identifies it as a generic resource and routes to the generic page instead of the core Service drawer.Please review sir

[illume]

Thanks @dibyanshu-pal-kushwaha

It looks like the lint CI check is failing. Please check the commands locally? format, lint, tsc, and test

Can you please check the open review comments?

[dibyanshu-pal-kushwaha]

@kahirokunn @illume , I made the changes by you and copilot , please review it.

[illume]

Thank you. Looking pretty good now.

Just the commit message needs tidying up. Can you please squash it?

Also the first commit message body should be rewritten. It currently contains previously squashed subject lines in the commit body.

frontend: src: Use kind and apiGroup for Link component routing
frontend: src: Change apiVersion to apiGroup and fix linting error

frontend: src: Fix check using kind and apiGroup

[alokdangre]

Screen.Recording.2026-02-01.173408.mp4

@illume @dibyanshu-pal-kushwaha it did'nt worked as expected

[alokdangre]

@dibyanshu-pal-kushwaha plzz test it locally and provide ss/sr

[alokdangre]

you can check if the object's class has the customResourceDefinition property. This property is typically present on dynamic classes created for erdbut absent on standard core classes

[alokdangre]

the matchesStandard check currently returns true for colliding crds because it compares the object's api group against its own constructor's apigroup,,, headlamp instantiates Custom Resources using dynamic classes that correctly match the crd api group, the check passes, and the standard drawer is still triggered.

[illume]

Thanks for the review @alokdangre

[dibyanshu-pal-kushwaha]

@illume @dibyanshu-pal-kushwaha it did'nt worked as expected

@alokdangre , please go through the issue #4267 (You misunderstood this issue) as this states that currently in the codebase , when any non-core Kubernetes services with same kind Service is there and we click it over there it navigates to the core Service details page instead of the dedicated Service page. Your Screenshot shows correctly as it does not navigate to any core services.

I have already tested it locally ......

This is core service navigation->

This is for Custom Service:

[dibyanshu-pal-kushwaha]

@illume Sir it worked correctly, I think.

[alokdangre]

@dibyanshu-pal-kushwaha i think maybe i have misunderstood it, but the same ss is working in current version as well

[kahirokunn]

You need to create a Custom Resource KubeObject like this:

class KService extends KubeObject<KServiceResource> {
  static kind = 'Service';
  static apiName = 'services';
  static apiVersion = 'serving.knative.dev/v1';
  static isNamespaced = true;
}

And to properly test this, You need to pass the retrieved object to the Link component as follows:

<Link kubeObject={knativeServiceObject} />

Currently, this navigates to the core Service resource (networking).

My issue would be resolved if the link navigates to the route defined for KService instead of the networking Service resource. If there is no route defined for KService, I believe it would be appropriate to navigate to the target resource page in the custom resources tab.

[illume]

@dibyanshu-pal-kushwaha can you please reply to the last review comment?