[Bug] Timeout countdown not propagated correctly in async Dubbo calls across multiple services

[imjyz]

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

Dubbo java 3.2.5, Open jdk 1.8

Steps to reproduce this issue

Consider three applications: A, B, and C, with the following call chain:

A → (3s timeout) → B → (6s timeout) → C

Application A has enable-timeout-countdown=true configured, which enables timeout propagation to downstream services.

In service B, when calling C using Dubbo’s built-in asynchronous mode:

@DubboReference(async = "true", timeout = 6000)
private CService cService;

cService.sayHello("world");

the effective timeout is correctly adjusted to less than 3 seconds, respecting the remaining time from the upstream caller (see Timeout Configuration Documentation).

However, if B invokes C via a plain CompletableFuture.supplyAsync(), like this:

CompletableFuture<String> future3 = CompletableFuture.supplyAsync(() -> {
    return asyncService.invoke("invoke call request3");
});

the timeout remains 6 seconds, because the Dubbo context (including the timeout countdown) is not propagated to the new thread.

What you expected to happen

I’m unsure whether this is a bug. I believe the timeout for async calls shouldn’t be modified automatically. If it’s by design, the correct way to write async invocations should be standardized and documented.

Anything else

Core code: org.apache.dubbo.rpc.support.RpcUtils#calculateTimeout

Object countdown = RpcContext.getClientAttachment().getObjectAttachment(TIME_COUNTDOWN_KEY);
if (countdown == null) {
    ......
} else {
    TimeoutCountDown timeoutCountDown = (TimeoutCountDown) countdown;
    timeout = (int) timeoutCountDown.timeRemaining(TimeUnit.MILLISECONDS);
    // pass timeout to remote server
    invocation.setObjectAttachment(TIMEOUT_ATTACHMENT_KEY, timeout);
}

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