[Bug] Instance-level registration fails when a single application acts as both provider and consumer with @DubboReference(scope = "remote")

[qq31715879]

Pre-check

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

Search before asking

• I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

下面是一份可直接用于 Apache Dubbo GitHub Issue 的英文标题与正文，表述偏工程化、可复现、符合开源社区沟通规范，也明确点出 Instance-level registration + same app acts as provider & consumer + @DubboReference(scope="remote") failure 这一关键组合条件。

---

Title

Instance-level registration fails when a single application acts as both provider and consumer with @DubboReference(scope = "remote")

---

Description

Background

We are using Apache Dubbo 3.x with instance-level (application-level) registration enabled.

In our deployment model, a single application instance acts as both a provider and a consumer.
This application internally references its own exported services using:

@DubboReference(scope = "remote")

The intention is to force remote invocation (even if the provider is co-located), which works correctly when provider and consumer are deployed as separate applications.

However, when provider and consumer coexist in the same application instance, the reference fails.

---

Problem Description

Under the following conditions, the Dubbo reference fails:

• Instance-level (application-level) registration enabled

• Same application instance acts as:

  • Service provider
  • Service consumer

• Consumer references the service using:

  @DubboReference(scope = "remote")

• Registry: Nacos (but the issue seems independent of registry implementation)

Observed behavior:

• Service export succeeds

• Instance is correctly registered

• Consumer fails to resolve or invoke the remote service

• No such failure occurs when:

  • Provider and consumer are deployed as separate applications
  • Or when scope = "local" / default behavior is used

---

Expected Behavior

When scope = "remote" is explicitly specified:

• The consumer should always perform remote service discovery and invocation
• Even if the provider is in the same JVM / same application instance
• Behavior should be consistent regardless of whether provider and consumer are deployed together or separately

---

Actual Behavior

• In a self-contained provider + consumer application, the reference fails

• Dubbo appears to:

  • Either incorrectly filter out the local instance
  • Or fail to correctly resolve remote endpoints under instance-level registration

• The same configuration works correctly when provider and consumer are split into different applications

---

Why This Is a Problem

This pattern is common in:

• Modular monoliths evolving toward microservices
• Applications using internal RPC abstraction for future service splitting
• Scenarios requiring strict remote call semantics for consistency testing, traffic routing, or governance

The current behavior makes it unsafe to use scope = "remote" in a self-provider-consumer scenario under instance-level registration.

---

Questions / Suspected Cause

• Is scope = "remote" intentionally unsupported when provider and consumer share the same application instance?

• Is there an issue in:

  • Instance filtering logic
  • Self-instance exclusion
  • Application-level metadata resolution

• Should scope = "remote" bypass local instance optimizations entirely in instance-level mode?

---

Steps to reproduce this issue

provider yaml :
dubbo:
application:
name: nest-test
logger: slf4j
qos-enable: false
qos-accept-foreign-ip: false
protocol:
name: tri
port: 50052
registry:
address: nacos://${nacos.address:127.0.0.1}:8848
register-mode: instance

provider test code
@DubboReference(scope = "remote")
private TestDubboApi testDubboApi;

What you expected to happen

I need to clarify whether, under instance-level registration, Dubbo intentionally does not support self-service testing using @DubboReference(scope = "remote"), or whether this behavior represents an unknown bug.

Anything else

In this demo, the RPC invocation works correctly when the provider and the consumer are started as separate applications.

Do you have a (mini) reproduction demo?

• Yes, I have a minimal reproduction demo to help resolve this issue more effectively!

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

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