[ISSUE #14094] fix(naming): validate serviceName and groupName in SubscribeServiceRequestHandler

[shichaoyuan]

Summary

• Add parameter validation for serviceName and groupName in SubscribeServiceRequestHandler before calling NamingUtils.getGroupedName()
• Throw NacosException with INVALID_PARAM (400) error code instead of letting IllegalArgumentException propagate as 500 error
• Add unit tests for blank serviceName and groupName scenarios

Root Cause

When gRPC subscribe request contains blank serviceName or groupName, NamingUtils.getGroupedName() throws IllegalArgumentException. The ErrorResponse.build(Throwable) method treats this as an unknown exception and returns error code 500 (FAIL). This causes SDK clients to:

1. Retry the invalid request infinitely
2. Become UNHEALTHY after retry exhaustion
3. Affect other valid service subscriptions

Solution

Validate parameters in the handler before calling getGroupedName(), throwing NacosException with INVALID_PARAM (400) error code. This allows:

• SDK to distinguish client errors (400, should not retry) from server errors (500, can retry)
• Immediate error return without affecting client health status

Test plan

• Add unit tests for blank serviceName validation
• Add unit tests for blank groupName validation
• Run existing SubscribeServiceRequestHandlerTest

Fixes #14094

[github-actions]

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格式）。

[wuyfee]

$\color{red}{FAILURE}$
DETAILS
✅ - docker: success
❌ - deploy (standalone & cluster & standalone_auth): failure
❌ - e2e-java-test (standalone & cluster & standalone_auth): skipped
❌ - e2e-go-test (standalone & cluster): skipped
❌ - e2e-cpp-test (standalone & cluster): skipped
❌ - e2e-csharp-test (standalone & cluster): skipped
❌ - e2e-nodejs-test (standalone & cluster): skipped
❌ - e2e-python-test (standalone & cluster): skipped
✅ - clean (standalone & cluster & standalone_auth): success

[WangzJi]

@shichaoyuan
It looks like some Unit Tests are failing in the CI environment. Could you please check the logs and ensure all tests pass locally?

[KomachiSion]

@shichaoyuan It looks like some Unit Tests are failing in the CI environment. Could you please check the logs and ensure all tests pass locally?

I will re-run the ci

[shichaoyuan]

@shichaoyuan It looks like some Unit Tests are failing in the CI environment. Could you please check the logs and ensure all tests pass locally?

I will re-run the ci

OK, I will check it based on the results of this run.

[shichaoyuan]

[INFO] Running com.alibaba.nacos.ai.index.MemoryMcpCacheIndexTest
09:10:54.709 [mcp-cache-cleanup] ERROR com.alibaba.nacos.ai.index.MemoryMcpCacheIndex -- Clean up expired mcp id and name cache failed.
java.lang.NullPointerException: Cannot invoke "com.alibaba.nacos.ai.config.McpCacheIndexProperties.getExpireTimeSeconds()" because "this.properties" is null
	at com.alibaba.nacos.ai.index.MemoryMcpCacheIndex.cleanupExpiredEntries(MemoryMcpCacheIndex.java:326)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
Error:  Tests run: 38, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.88 s <<< FAILURE! -- in com.alibaba.nacos.ai.index.MemoryMcpCacheIndexTest
Error:  com.alibaba.nacos.ai.index.MemoryMcpCacheIndexTest.testCleanupExpiredEntriesDoesNotAffectValidEntries -- Time elapsed: 2.209 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <id2> but was: <null>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
	at com.alibaba.nacos.ai.index.MemoryMcpCacheIndexTest.testCleanupExpiredEntriesDoesNotAffectValidEntries(MemoryMcpCacheIndexTest.java:638)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

It looks like the MemoryMcpCacheIndexTest test case isn't robust enough