Skip to content

fix(naming): do not force clusterName to DEFAULT in v3 HTTP API#14778

Open
daguimu wants to merge 1 commit intoalibaba:developfrom
daguimu:fix/v3-api-cluster-default-mismatch-14650
Open

fix(naming): do not force clusterName to DEFAULT in v3 HTTP API#14778
daguimu wants to merge 1 commit intoalibaba:developfrom
daguimu:fix/v3-api-cluster-default-mismatch-14650

Conversation

@daguimu
Copy link
Copy Markdown
Contributor

@daguimu daguimu commented Mar 29, 2026

Problem

When calling the v3 HTTP API to list instances without specifying a clusterName, the API returns NOT_FOUND for services that use non-default cluster names (e.g., cluster-hba). The same query via gRPC correctly returns all instances.

Root Cause

InstanceListForm.fillDefaultValue() forces an empty clusterName to "DEFAULT". Then CatalogServiceV2Impl.listInstances() does an exact match — if the service has no cluster named "DEFAULT", it throws NacosException.NOT_FOUND.

The gRPC path (ServiceQueryRequestHandler) treats empty cluster as an empty string, which flows into ServiceUtil.doSelectInstances() where an empty cluster produces an empty clusterSets, causing checkCluster() to return true for all instances.

Fix

  • InstanceListForm.fillDefaultValue(): Use StringUtils.EMPTY instead of UtilsAndCommons.DEFAULT_CLUSTER_NAME when clusterName is blank, so the v3 HTTP path passes an empty string just like gRPC does.
  • CatalogServiceV2Impl.listInstances(): Skip the cluster-existence check when clusterName is blank, letting ServiceUtil.selectInstances() handle the empty-cluster case correctly (return all instances).

Tests Added

Change Point Test
InstanceListForm: blank clusterName → empty string InstanceListFormTest.testFillDefaultValueWhenClusterNameIsBlank()
InstanceListForm: provided clusterName preserved InstanceListFormTest.testFillDefaultValueWhenClusterNameIsProvided()
InstanceListForm: default namespace/group InstanceListFormTest.testFillDefaultValueForNamespaceAndGroup()
InstanceListForm: missing serviceName throws InstanceListFormTest.testValidateThrowsExceptionWhenServiceNameIsBlank()
CatalogServiceV2Impl: blank cluster returns all instances CatalogServiceV2ImplTest.testListInstancesWithBlankClusterNameReturnsAll()
CatalogServiceV2Impl: null cluster returns all instances CatalogServiceV2ImplTest.testListInstancesWithNullClusterNameReturnsAll()

Impact

Only affects the v3 HTTP instance-list endpoint when clusterName is omitted. No change to gRPC behavior or any other API.

Fixes #14650

@github-actions
Copy link
Copy Markdown

Thanks for your this PR. 🙏
Please check again for your PR changes whether contains any usage/api/configuration change such as Add new API , Add new configuration, Change default value of configuration.
If so, please add or update documents(markdown type) in docs/next/ for repository nacos-group/nacos-group.github.io


感谢您提交的PR。 🙏
请再次查看您的PR内容,确认是否包含任何使用方式/API/配置参数的变更,如:新增API新增配置参数修改默认配置等操作。
如果是,请确保在提交之前,在仓库nacos-group/nacos-group.github.io中的docs/next/目录下添加或更新文档(markdown格式)。

When clusterName is not specified, InstanceListForm.fillDefaultValue()
was forcing it to "DEFAULT", causing v3 HTTP API to return NOT_FOUND
for services using non-default cluster names. The gRPC path treats
empty cluster as "return all instances", but v3 HTTP did an exact
match against "DEFAULT".

Change fillDefaultValue() to use empty string instead of DEFAULT_CLUSTER_NAME,
and add a blank-check in CatalogServiceV2Impl.listInstances() to skip the
cluster existence validation when clusterName is blank, aligning behavior
with the gRPC path (ServiceUtil.doSelectInstances).

Fixes alibaba#14650
@daguimu daguimu force-pushed the fix/v3-api-cluster-default-mismatch-14650 branch from 397623a to e2146c5 Compare March 29, 2026 09:17
@KomachiSion
Copy link
Copy Markdown
Collaborator

Duplicate with #14674

If this PR no response and no match the merged status, This PR will be merged.

@KomachiSion KomachiSion added pending On hold due to dependency or release status/duplicate This issue or pull request already exists labels Apr 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pending On hold due to dependency or release status/duplicate This issue or pull request already exists

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] nacos v3 api 和 grpc客户端机制不一致

2 participants