Alanxtl opened a new issue, #3596:
URL: https://github.com/apache/dubbo-go/issues/3596
Parent issue: #3595
## Problem
The client invocation path currently treats
`ctx.Value(constant.AttachmentKey)` as an implicit source of RPC attachments.
In `client.generateInvocation`, values stored in the Context are copied into
`Invocation.attachments` and may then be serialized as Dubbo attachments,
Triple HTTP headers, or Dubbo3/gRPC metadata.
This means a call such as:
```go
ctx = context.WithValue(ctx, constant.AttachmentKey, map[string]any{
"tenant-id": "tenant-a",
})
client.CallUnary(ctx, req, resp, "GetUser")
```
has hidden RPC inputs that are not visible in the call options or business
request. The same mechanism can also affect RPC control fields such as timeout
and retries.
The server side may expose inbound metadata both through
`ctx.Value(constant.AttachmentKey)` and through `Invocation.attachments`, which
further blurs the boundary between request lifecycle context and transport
metadata.
## Goals
- Make outbound RPC metadata explicit at the call site.
- Keep `context.Context` focused on cancellation, deadlines, tracing, and
local request-scoped state.
- Preserve existing users through a documented compatibility path.
- Ensure explicit metadata has deterministic precedence over legacy metadata.
- Prevent a metadata timeout from extending the caller's Context deadline.
## Proposed approach
1. Add explicit per-call APIs, for example:
```go
client.WithAttachment("tenant-id", "tenant-a")
client.WithAttachments(map[string]any{...})
```
Store these values directly in `CallOptions` and merge them into the
Invocation without routing them through `context.Context`.
2. Keep support for `ctx.Value(constant.AttachmentKey)` temporarily behind a
legacy compatibility mode. Mark the mechanism deprecated and document the
migration to explicit call options.
3. Define merge precedence as:
```text
explicit CallOption attachments > legacy Context attachments > defaults
```
4. Add a configuration or option to disable legacy Context attachments for
applications that want strict behavior. Consider making the default disabled in
a future major release.
5. Keep inbound metadata available to server handlers through a documented
read-only API during migration, but do not automatically treat it as outbound
metadata for downstream calls.
6. Define timeout precedence separately: an existing Context deadline must
never be extended by an attachment or per-call timeout.
## Acceptance criteria
- [ ] Explicit per-call attachment APIs exist for generated and generic
client calls where applicable.
- [ ] Explicit attachments are merged directly into `Invocation.attachments`.
- [ ] Existing `ctx.Value(constant.AttachmentKey)` callers remain functional
while compatibility mode is enabled.
- [ ] Explicit attachments override legacy Context attachments for the same
key.
- [ ] Legacy Context attachment propagation can be disabled.
- [ ] Context deadline behavior is tested and cannot be extended by
attachment timeout values.
- [ ] Tests cover Dubbo, Triple, and Dubbo3/gRPC metadata propagation.
- [ ] Documentation clearly distinguishes Context values, business request
fields, RPC metadata, and Invocation attributes.
## Non-goals
- Do not remove wire-level Dubbo attachments or Triple/gRPC metadata.
- Do not change business request schemas as part of this issue.
- Do not automatically propagate all inbound metadata to downstream RPCs.
--
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]
