When search for resources in a specified cluster, the response of two url query way is different.

[KubeKyrie]

What happened?

When search for resources in a specified cluster, the response of two url query way is different.
In this case, actually cluster-1 not exists.
In the 2nd way, we may mistakenly assume that deployment does not exist in cluster-1, rather than cluster-1
So I think the 2nd way should also be Error from server (BadRequest): the server could not find the requested cluster

[root@qin-dev ~]# kubectl get --raw="/apis/clusterpedia.io/v1beta1/resources/clusters/cluster-1/apis/apps/v1/deployments"
Error from server (BadRequest): the server could not find the requested cluster
[root@qin-dev ~]#
[root@qin-dev ~]# kubectl get --raw="/apis/clusterpedia.io/v1beta1/resources/apis/apps/v1/deployments?clusters=cluster-1"
{"kind":"DeploymentList","apiVersion":"apps/v1","metadata":{},"items":[]}
[root@qin-dev ~]#
[root@qin-dev ~]# kubectl get pediacluster
NAME              READY   VERSION   APISERVER
cluster-example   True    v1.27.5   https://x.x.x.x:6443

What did you expect to happen?

Error from server (BadRequest): the server could not find the requested cluster

How can we reproduce it (as minimally and precisely as possible)?

Just kubectl get --raw="/apis/clusterpedia.io/v1beta1/resources/apis/apps/v1/deployments?clusters=cluster-1"

Anything else we need to know?

Nope

Clusterpedia Version

None

None

# replace the pod name of clusterpedia apiserver
$ kubectl -n clusterpedia-system exec {clusterpedia-apiserver-pod-name} -- apiserver --version=raw
# paste output here

# replace the pod name of clusterpedia clustersynchro-manager
$ kubectl -n clusterpedia-system exec {clustersynchro-manager-pod-name} -- clustersynchro-manager --version=raw
# paste output here

Host Kubernetes version

None

None

$ kubectl version
# paste output here

[clusterpedia-bot]

Hi @KubeKyrie,
Thanks for opening an issue!
We will look into it as soon as possible.

Details

Instructions for interacting with me using comments are available here.
If you have questions or suggestions related to my behavior, please file an issue against the gh-ci-bot repository.

[khareyash05]

Hey! Such a great find @KubeKyrie. Maybe creating a unique token for each cluster and storing it in the storage layer might help.Then we can maybe create a sort of a middleware which checks on each request

[Iceber]

This is a known result, and for global searches (paths that do not contain clusters/< cluster >), the parameters passed will only affect the results returned, but no errors will be reported unless the parameters are abnormal.