mochengqian opened a new issue, #949: URL: https://github.com/apache/dubbo-go-pixiu/issues/949
> ⚠️ **This is an RFC for design discussion, not an implementation task.** Please do not open a PR that simply changes the warning to `panic` — the migration path is what this issue exists to align on. The issue will not be labeled `contribute welcome` until a direction is agreed. ## Background Surfaced in #932 (review thread starting at https://github.com/apache/dubbo-go-pixiu/pull/932#issuecomment-4566120689). Reviewer's framing: *"ID is an identity, not a name; identity collisions should fail, not auto-rename. Neither static config nor dynamic registration should support duplicate IDs — I can't think of a scenario where duplicate IDs are legitimate."* ## Current behavior Endpoint ID collisions are handled differently across three paths today: | Path | Behavior on collision | |---|---| | Static YAML assembly (`assembleClusterEndpoints`) | Warn + suffix the second entry as `<id>-2` | | Dynamic `SetEndpoint`, explicit ID | Replace the slot in place (registry-update semantics, fixed in #932) | | Dynamic `SetEndpoint`, empty ID + hash collision + different content | Warn + suffix as `<hash>-2` | The argument for hard-fail: under all three paths, a duplicate ID is almost certainly an operator mistake or an adapter bug. The current behavior (suffix or replace) silently keeps the cluster running with state the operator did not intend. ## Proposal direction (to be discussed, not committed to) Phase the change over one minor-release deprecation window: 1. **Today → v1.x.next** — Keep current behavior. Add a `pixiu_endpoint_id_collision_total{cluster, source}` counter so operators can see if their config is affected. Also log at WARN with a deprecation note pointing at this issue. 2. **v1.x.next → v1.(x+1)** — Introduce `cluster.strict_unique_ids: true` opt-in flag. When set, duplicate IDs fail cluster initialization (static) or are rejected by `SetEndpoint` (dynamic). Default remains current behavior. 3. **v1.(x+2)** — Flip the default to `true`. Provide `strict_unique_ids: false` as an escape hatch for one more minor version, then remove. ## Open questions - Does the static-YAML path actually have legitimate use cases for duplicate IDs that we should preserve? (Sister deployments, blue/green, ...?) - For the dynamic empty-ID hash collision case: does hard-fail even make sense, or should that path stay tolerant since callers aren't claiming identity? - Are there integration tests / staging deployments that would catch a misconfig before production fail? - Version targets — v1.3 vs v1.4 for the strict default? ## Out of scope for this RFC - Implementation PRs. They follow once direction is agreed. - Endpoint deduplication semantics inside a single `SetEndpoint` call — that's settled in #932. ## Owner Looking for a maintainer to drive the design conversation. Once Phase 1 lands and the metric is observable, the rest can be split into contributor-sized PRs. -- 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]
