nanjiek commented on issue #3240: URL: https://github.com/apache/dubbo-go/issues/3240#issuecomment-4332960634
本 PR 提交的单测 TestTripleClientOTELTraceparentIsolation 已经完整覆盖并验证了修复效果，具体逻辑如下： 1. 针对“根因 1”（旧 traceparent 覆盖新值）的验证 测试构造： 单测中手动在 upstreamCtx 的 AttachmentKey 中注入了一个 incomingTraceparent（模拟入站请求）。 校验逻辑： 在模拟 Triple Invoker 执行时，通过断言 assert.NotEqual(t, incomingTraceparent, invoker.calls[0].outgoingTraceparent)，验证了最终发出的 Header 并非入站时的旧值。 结论： 证明了修复后的 parseInvocation 逻辑能够正确识别并避免用 ctx 中的旧 Attachment 覆盖 OTEL Filter 注入的新 Trace 上下文。 2. 针对“根因 2”（共享 Header 导致 Trace 累积）的验证 测试构造： 单测模拟了同一个服务实例内串行发起两个下游 RPC（Call B 和 Call C）。 校验逻辑： 独立性校验： 校验了两次调用的 traceparent 完全不同，且各自对应其 client span。 提取规则校验： 最核心的断言是 assert.Equal(t, clientCReadOnly.SpanContext().SpanID(), clientCOutgoing.spanID)。由于 http.Header.Get() 默认取第一个值，如果修复无效（即发生了 Append 累积），则 Call C 获取到的仍会是 Call B 的 ID。 结论： 断言通过证明了 mergeAttachmentToOutgoing 现在能够正确处理 Header 隔离，确保每次调用发送的是当前 Context 关联的正确 Trace 信息。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
