[General] how should Dubbo handle non-Dubbo Spring Cloud instances in Nacos?

[onceMisery]

Pre-check

• I am sure that all the content I provide is in English.

Apache Dubbo Component

Java SDK (apache/dubbo)

Details

Hi Dubbo community,

I would like to start a discussion about the behavior described in Issue #16108

Background
When Spring Cloud services and Dubbo services are registered in the same Nacos namespace, a Dubbo consumer may discover Spring Cloud instances that do not contain valid Dubbo metadata. In this case, Dubbo currently tries to build invokers from those instances and may finally throw an "Unsupported protocol" / "Cannot create invokers" exception.

Current issue
From my investigation, the problem is related to the interaction between Spring Cloud service instance customization and Dubbo metadata matching:

1. Spring Cloud instances may be assigned REST-style metadata during notification customization.
2. When the consumer reference does not explicitly specify a protocol, the matching logic may still treat those non-Dubbo instances as candidates.
3. As a result, the Dubbo consumer does not skip these instances gracefully and instead fails during invoker creation.
   Expected behavior

My expectation is that if a discovered instance is not a real Dubbo provider and does not contain valid Dubbo service metadata for the consumer, Dubbo should skip it gracefully instead of throwing an exception. The consumer should continue waiting for actual Dubbo provider instances.

Proposed direction
My current fix idea is to make the matching/filtering logic stricter so that non-Dubbo Spring Cloud instances are excluded earlier during service matching, especially when the consumer protocol is not explicitly specified.

Draft PR
I have prepared a draft change here for reference: onceMisery#1

Questions for the community

1. Do you agree that the expected behavior should be to ignore non-Dubbo Spring Cloud instances in this scenario?
2. Is tightening the matching logic the right direction, or would you prefer handling this at a different layer?
3. Are there any compatibility concerns I should consider before submitting the final PR to apache/dubbo?

Any feedback is appreciated. After consensus, I will update the implementation accordingly and prepare the formal PR.

Code of Conduct

• I agree to follow this project's Code of Conduct