Why Dubbo 2.7.x Can’t Return Implicit Parameters from Provider to Consumer

In a previous article "聊聊dubbo协议" the transmission of attachments between consumer and provider was discussed, leaving an open question: why does Dubbo 2.7.x not support returning implicit parameters from the provider to the consumer? This follow‑up provides the answer.

Capture Packets to Determine Whether Provider Sent or Consumer Dropped

The following test is based on Dubbo 2.7.6.

Add the following code on the provider side:

RpcContext.getServerContext().setAttachment("hello", "from_provider");

Run the provider, continuously invoke from the consumer, and capture packets: sudo tcpdump -i any -vv -A -n port 20880 You can see the provider returned the parameter, indicating the consumer lost the data.

Analyzing Code Differences Between 2.6.x and 2.7.x

When the consumer receives the provider's response, the processing flow is: DecodeableRpcResult → decode →

case DubboCodec.RESPONSE_VALUE_WITH_ATTACHMENTS → handleAttachment

Breakpoint debugging shows that implicit parameters exist in DecodeableRpcResult.

Let's look at the 2.6.x implementation:

In 2.6.x, RpcResult attachments are passed to RpcContext via a filter, allowing retrieval of implicit parameters.

In 2.7.x, Result attachments are not used.

Although the parameters are transmitted, the consumer does not place them into RpcContext, making them unusable.

Why Does 2.7.x Not Process It?

In 2.6.x, Dubbo's response object was only RpcResult.

In 2.7.x, RpcResult was removed and replaced by AsyncRpcResult and AppResponse. AppResponse holds the actual return data and its attachments contain implicit parameters, but it is wrapped inside AsyncRpcResult. The invoke method receives AsyncRpcResult, and when extracting data from AppResponse, the attachments are lost.

A major improvement in 2.7.x is better async support; the refactoring of RpcResult is likely the cause of the lost implicit parameters.

How Does Dubbo Protocol Handle Compatibility?

The RmiProtocol class shows version compatibility handling for the boundaries 2.7.0 and 2.6.3.

Version information is obtained from the provider's URL, preferring the release parameter, then dubbo, to determine the provider's Dubbo version:

dubbo://127.0.0.1:20880/com.newbooo.basic.api.SampleService?anyhost=true&application=ddog-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.newbooo.basic.api.SampleService&methods=getByUid&owner=roshilikang&pid=96150&release=2.7.6&retries=7&side=provider&timestamp=1614235399505

Historically, before Dubbo 2.6.3 the dubbo URL parameter represented the Dubbo version; from 2.6.3 onward it represents the Dubbo protocol version.

[2.5.3, 2.6.3)

versions use the dubbo URL parameter for the Dubbo version (>=2.0.0 && <=2.6.2). [2.6.3, 2.7.0) versions cannot obtain the Dubbo version from the URL; the protocol version is fixed at 2.0.2 via the dubbo parameter.

From 2.7.0 onward, the Dubbo version is taken from the URL release parameter, while the protocol version remains 2.0.2 in the dubbo parameter.

Conclusion

This analysis shows why Dubbo 2.7.x cannot return implicit parameters from the provider, which appears to be a bug in the 2.7 series.