fix(codec): support transinfo in attachment codec

[CoderPoet]

What type of PR is this?

fix: https://github.com/kitex-contrib/codec-dubbo/issues/84

Check the PR title.

• [x] This PR title match the format: \<type>(optional scope): \<description>
• [x] The description of this PR title is user-oriented and clear enough for others to understand.
• [x] Attach the PR updating the user documentation if the current PR requires user awareness at the usage level. User docs repo

(Optional) Translate the PR title into Chinese.

在 attachment 编解码中支持处理 transinfo

(Optional) More detailed description for this PR(en: English/zh: Chinese).

en: support transinfo in attachment codec zh(optional): 在 attachment 编解码器中支持 TransInfo

(Optional) Which issue(s) this PR fixes:

fix: https://github.com/kitex-contrib/codec-dubbo/issues/84

(optional) The PR that updates user documentation:

[GuangmingLuo]

Yes, please add to _typos.toml.

[CoderPoet]

BTW, maybe we should exclude "go.mod" in _typos.toml.

+1

I'll see how I can change the rules

[CoderPoet]

BTW, maybe we should exclude "go.mod" in _typos.toml.

done

[CoderPoet]

Yes, please add to _typos.toml.

done

[bytedance-oss-robot[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: CoderPoet, DMwangnima To complete the pull request process, please assign marina-sakai after the PR has been reviewed. You can assign the PR to them by writing /assign @marina-sakai in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/kitex-contrib/codec-dubbo/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[nobody-s07]

This PR introduces an issue where Kitex client calls Dubbo service:

The corresponding Java code is as follows, where 'attachments' is a Map with keys of type String:

In this PR, the attachment contains data with keys of type uint16:

        //  pkg/dubbo_spec/attachment.go:  line 56 ~ line 58
    for k, v := range transInfo.TransIntInfo() {
        result[k] = v
    }

[nobody-s07]

Besides,the trace context was not correctly propagated to dubbo server side ( extracting trace context through opentelemetry-javaagent ):

I compared the 'attachments' received by the Dubbo service when called by the Dubbo client and the Kitex client, there are some differences in the keys within the 'attachments'. called by dubbo client: called by kitex client:

I made a local modification to the codec-dubbo, removing the prefix RPC_TRANSIT_, and found that the Dubbo server could correctly parse the trace context:

I'm not sure if directly removing the prefix(RPC_TRANSIT_) will introduce other issues, but currently, it seems that this prefix causes the Dubbo server to be unable to parse the trace context.

[CoderPoet]

This PR introduces an issue where Kitex client calls Dubbo service:

The corresponding Java code is as follows, where 'attachments' is a Map with keys of type String:

In this PR, the attachment contains data with keys of type uint16:

        //  pkg/dubbo_spec/attachment.go:  line 56 ~ line 58
  for k, v := range transInfo.TransIntInfo() {
      result[k] = v
  }

@nobody-s07 Sorry for not having enough testing before causing the issue. This PR（https://github.com/kitex-contrib/codec-dubbo/pull/90 ） has fixed the issue, you can try again

[nobody-s07]

@CoderPoet Thank you for your resolution! Now the trace context is correctly passed to the Dubbo service.

[DMwangnima]

@CoderPoet Thank you for your resolution! Now the trace context is correctly passed to the Dubbo service.

Hi! Thank you very much for pointing this out. Would you be interested in contributing a testcase to https://github.com/kitex-contrib/codec-dubbo-tests ?