Alanxtl opened a new issue, #3595: URL: https://github.com/apache/dubbo-go/issues/3595
## Problem dubbo-go exposes `context.Context` throughout the client, invoker, cluster, filter, protocol, and server layers, but the meaning and propagation rules are not consistent across protocols. Today, the implementation mixes several concerns: - Go request lifecycle: cancellation and deadlines. - RPC metadata: attachments, headers, and gRPC metadata. - Internal invocation attributes. - Protocol-specific timeout and metadata mechanisms. - Context values used as an implicit source of RPC attachments. This makes it difficult to answer basic questions consistently: - Does caller cancellation reach the remote operation? - Which timeout wins when `ctx.Deadline()` and an attachment timeout are both present? - Which context values are local-only and which are serialized onto the wire? - Should inbound metadata automatically be propagated to downstream RPCs? - Do Dubbo, Triple, Dubbo3/gRPC, JSON-RPC, and REST preserve the same context semantics? ## Examples - The client path passes `ctx` to `Invoker.Invoke`, while also reading `ctx.Value(constant.AttachmentKey)` into `Invocation.attachments`. - Traditional Dubbo primarily uses invocation attachments for timeout and tracing, and its server-side request handling rebuilds a context from `context.Background()`. - Triple and Dubbo3 convert invocation attachments into outgoing HTTP/gRPC metadata. - Server paths may represent the same inbound metadata both in the Context and in `Invocation.attachments`. - Context-to-attachment conversion helpers create a second abstraction for moving data between Context and Invocation. Related issue: #3557 tracks several concrete cases where request context is dropped via `context.Background()`. ## Proposed direction Define and document a single context model with explicit boundaries: 1. `context.Context` owns cancellation, deadlines, tracing, and local request-scoped state. 2. RPC metadata/attachments own data intentionally sent over the wire. 3. Invocation attributes own internal, local-only control data. 4. Protocol adapters explicitly translate metadata to and from wire representations. 5. A caller deadline is never extended by a protocol attachment timeout. 6. Inbound metadata is not automatically forwarded to downstream RPCs unless propagation is explicitly requested. 7. Existing behavior is migrated through compatibility shims and deprecation periods. ## Scope - Audit context creation and propagation across all client, server, invoker, cluster, filter, and protocol paths. - Define timeout precedence and cancellation semantics. - Define inbound/outbound metadata APIs and ownership. - Align Dubbo, Triple, Dubbo3/gRPC, JSON-RPC, and REST behavior where the transport allows it. - Add conformance tests for cancellation, deadlines, metadata propagation, and protocol-specific compatibility behavior. - Update documentation and samples. ## Acceptance criteria - [ ] A documented context/metadata model exists. - [ ] Context propagation and timeout precedence are defined for each supported protocol. - [ ] New APIs make outbound RPC metadata explicit. - [ ] Existing users have a documented compatibility and migration path. - [ ] Cross-protocol conformance tests cover cancellation, deadlines, and metadata propagation. - [ ] Context values are not automatically serialized as RPC parameters except through an explicit legacy compatibility mode. ## Sub-issues - #TBD: Stop `ctx.Value` from being an implicit RPC parameter source while preserving compatibility. -- 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]
