Repository navigation
Fix metadata compatibility for mixed Dubbo and Triple protocols - #16525
hehuang139 wants to merge 2 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 3.3 #16525 +/- ##
============================================
+ Coverage 60.89% 60.93% +0.04%
- Complexity 11753 11754 +1
============================================
Files 1953 1953
Lines 89278 89286 +8
Branches 13475 13478 +3
============================================
+ Hits 54367 54408 +41
+ Misses 29329 29298 -31
+ Partials 5582 5580 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Fixed the Java 21 and 25 CI failures in de142e9. Both jobs failed because the new RPC test reused cached Triple port Added ten configuration cases covering application-property priority over the parameters map, empty or unrelated parameters, and fallback without an application configuration. The protocol-selection conditions highlighted by Codecov now have full branch coverage in the local JaCoCo report. Validation on Linux:
Updated the PR description with these results. CI will validate the updated commit. |
What is the purpose of the change?
Fixes #15641.
With local metadata and both
dubboandtriprotocols, MetadataService V1 can be exported over Dubbo while the advertised URL points to the Triple V2 endpoint. A Dubbo 3.1.11 consumer then calls the V1 interface on that endpoint and fails withUNIMPLEMENTED: Invoker for gRPC not found, even withonly-use-metadata-v2=false.Export both metadata versions over Triple when V2 is enabled and advertise the V1 URL parameters for compatibility. Keep the V2 capability marker so current consumers still negotiate V2. Honor an explicit metadata protocol from either the application property or its parameters map when deciding whether to enable V2. The RPC tests allocate available protocol ports to avoid the cached default port colliding with other tests.
Validation on Linux with Maven 3.9.9:
50051; the revised test passed with that port occupied.spotless:checkfor both changed modules andgit diff --check.Test commands (after installing reactor dependencies, with
JAVA_HOMEandPATHset to the indicated JDK):Checklist