Supported IDL-based service naming for application-level discovery: Fixes #15365 #15888
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 3.3 #15888 +/- ##
============================================
- Coverage 60.68% 58.75% -1.94%
+ Complexity 11702 15 -11687
============================================
Files 1946 1947 +1
Lines 88701 88737 +36
Branches 13374 13381 +7
============================================
- Hits 53831 52133 -1698
- Misses 29356 30965 +1609
- Partials 5514 5639 +125
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I made sure that the change is fully gated by configuration and should not affect the default behavior. I think CI is enabling IDL mode implicitly or exercising a different application-level discovery path. |
|
@zrlw @heliang666s Could you please review this and let me know if there are any adjustments I need to make? |
|
Looking deeper into the CI failures, they seem to involve triple application-level discovery, which uses stub-based resolution and may implicitly rely on IDL service names. This discovery path differs from the default behavior and could explain why the issue surfaces only in these test cases. |
What is the purpose of the change?
This PR resolves service discovery failures in Dubbo IDL applications where the declared Protobuf package differs from the Java package. When explicitly enabled, Dubbo registers and discovers services using their original IDL interface name instead of the generated Java interface name. This maintains backward compatibility and aligns service discovery behavior with the IDL-based service definitions.
Fixes #15365
Checklist