Tsukikage7 commented on issue #3562: URL: https://github.com/apache/dubbo-go/issues/3562#issuecomment-5131193627
@Alanxtl, after the recent coordination on #3338 and a new review of the currently active observability work, I would like to narrow my ownership proposal under #3562 so that I do not duplicate work already being implemented by other contributors. ## Work I would like to own ### 1. Shared observability semantic contract and current-state audit I would like to take responsibility for Workstream 1, including: - inventorying the existing Metrics, Trace, Log and Metadata semantics; - defining the cross-signal mapping for stable fields such as `service`, `method`, `protocol`, `side`, `error_type`, `error_code` and `error_source`; - defining low-cardinality and high-cardinality boundaries; - documenting compatibility requirements for existing metrics, configuration and logger behavior; - producing the shared test matrix and the file/owner overlap matrix for follow-up PRs. This work will start as an audit and reviewable contract. It will not modify the implementation currently owned by #3337, #3338 or #3356. ### 2. Proposed shared RPC error-classification core Subject to maintainer and current-contributor confirmation, I would also like to own the narrow cross-signal classification core from Workstream 2. The goal would be a minimal typed classification result that can eventually be reused by Metrics, Trace and structured logging without each signal parsing error strings independently. The first implementation would be constrained to: - preserving the original error cause; - using `errors.Is`, `errors.As` and typed protocol errors; - covering cancellation, deadline exceeded and existing Triple/Dubbo structured error codes; - safely falling back to `unknown` when no reliable structured code exists; - adding table-driven and wrapped-error tests; - integrating only with the first consumer explicitly agreed by the relevant owner. I will not submit an unused abstraction package with no real consumer. ## Explicit non-overlap boundaries - #3338 and PR #3551 remain with @jiaming2li and the existing assignees. I will not implement Trace span lifecycle, diagnostic events, propagation or Trace-specific error attributes. - #3337 remains with its current owner. I will not change metric names, labels, counters, dashboards or cardinality behavior without agreement. - #3356 and PR #3463 remain with their current contributors. I will not implement or replace `MetadataError` or metadata metrics. - I will not take the filter auto-injection/default-on work proposed in #3568. - I will not create a parallel implementation of the existing dubbo-admin PromQL/trace-diagnosis work. ## Coordination questions @Saramanda9988, are you already changing `metrics/rpc/error_classifier.go` as part of #3337? If not, would you be comfortable with the current Metrics classifier becoming the first consumer of a shared classification core, while all metric names, labels and collection behavior remain under #3337? @AlexStocks @Modo-me, #3568 also proposes Dubbo protocol error classification. If that implementation is already planned or in progress, please let me know and I will not duplicate it. If useful, a possible boundary would be: - shared protocol-neutral classifier core under #3562; - Metrics/default-filter wiring and the #3568-specific integration under #3568. @Alanxtl, could you please confirm whether this ownership split is appropriate, and where the shared classification API should live? Until these boundaries are confirmed, I will only continue the audit/semantic-contract work and will not start implementation code. -- 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]
