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

[imjyz]

Pre-check

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

Search before asking

• [x] 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?

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

Code of Conduct

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

[gobardan1707]

@imjyz i can solve this issue can you please assign it to me

[imjyz]

@gobardan1707 I'm not sure if this is a bug — I'm still waiting for feedback from the community.

[RainYuY]

I think for async calls, we consider the call completed when it finishes. Therefore, the deadline (timeout) should continue counting at subsequent nodes. This is my opinion—I suggest we keep the issue open for discussion, as it’s a valuable topic. Thanks for your issue and feedback!

[EarthChen]

I think this is as expected, and an asynchronous thread started independently can be regarded as a new request.