Fix misleading NPE when request parameter is not Serializable

[chensishang]

When a Dubbo service is called with non-serializable parameters, the invocation deserialization fails silently and path becomes null. This null path is then passed to GroupServiceKeyCache which uses a ConcurrentHashMap that does not accept null keys, resulting in a confusing NullPointerException.

Added a null check for path in DubboProtocol.getInvoker() to throw a clear RemotingException with a meaningful message pointing users to the actual cause (non-serializable parameters).

Fixes #16293

What is the purpose of the change?

Checklist

• Make sure there is a GitHub_issue field for the change.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Make sure gitHub actions can pass. Why the workflow is failing and how to fix it?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.77%. Comparing base (b65573e) to head (9bc0d46).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16299      +/-   ##
============================================
- Coverage     60.80%   60.77%   -0.04%     
- Complexity    11766    11771       +5     
============================================
  Files          1953     1953              
  Lines         89188    89191       +3     
  Branches      13454    13455       +1     
============================================
- Hits          54235    54206      -29     
- Misses        29391    29414      +23     
- Partials       5562     5571       +9     

Flag	Coverage Δ
integration-tests-java21	32.12% <0.00%> (-0.01%)	⬇️
integration-tests-java8	32.24% <0.00%> (+<0.01%)	⬆️
samples-tests-java21	32.18% <0.00%> (+<0.01%)	⬆️
samples-tests-java8	29.83% <0.00%> (-0.03%)	⬇️
unit-tests-java11	59.01% <100.00%> (-0.04%)	⬇️
unit-tests-java17	58.49% <100.00%> (-0.04%)	⬇️
unit-tests-java21	58.51% <100.00%> (+0.02%)	⬆️
unit-tests-java25	58.47% <100.00%> (+<0.01%)	⬆️
unit-tests-java8	59.05% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[chensishang]

Hi reviewers, I noticed the Codecov check failed with "0% coverage". After checking, this seems to be due to an incomplete report upload ("HEAD比BASE少7次上传") rather than a problem with the code change itself.

I have already added a unit test (testGetInvokerThrowsOnNullPath) which covers the new null-check logic, and it passes locally. The Codecov result appears to be a false negative caused by the CI infrastructure.

Could you please take another look? Thanks!

[zrlw]

LGTM

[chensishang]

Thanks for the review!

[chensishang]

Hi @zrlw, thanks for the review!

The PR contains two commits: the actual fix (6a870129) and a merge commit for syncing with the latest 3.3 branch. The only real change is in DubboProtocol.java and DubboProtocolTest.java.

The maintainer can squash on merge if needed. Sorry for the noise!