You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@dubbo.apache.org by "mochengqian (via GitHub)" <gi...@apache.org> on 2026/05/29 02:10:41 UTC

[I] RFC: treat duplicate endpoint IDs as a hard configuration error [dubbo-go-pixiu]

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: notifications-unsubscribe@dubbo.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org

Re: [I] RFC: treat duplicate endpoint IDs as a hard configuration error [dubbo-go-pixiu]

Posted by "mochengqian (via GitHub)" <gi...@apache.org>.

mochengqian commented on issue #949:
URL: https://github.com/apache/dubbo-go-pixiu/issues/949#issuecomment-4642990871

Picking this back up to move the design conversation forward (keeping it design-only — no implementation PR until we agree direction, per the issue header).

## Position on the open questions

**1. Does the static-YAML path have legitimate duplicate-ID use cases?**
I can't find one. ID is identity; two static entries with the same ID are two configs claiming to be the same runtime instance, which is incoherent. Blue/green and sister deployments are *different* instances and should carry different IDs (or be split across clusters) — they don't need ID reuse. So I'd treat static duplicate-ID as a hard error once the deprecation window closes.

**2. Empty-ID hash-collision case — should hard-fail apply?**
No, and I think this is the important nuance. When the caller supplies no ID, it is explicitly *not* claiming identity — it's saying "give me a runtime ID." Two empty-ID payloads that hash-collide but differ in content are two legitimate distinct endpoints (the static-assemble suffix rule already handles this correctly). Hard-failing here would punish callers for not claiming an identity they were never required to claim. **So the strict rule should apply only to the explicit-ID paths** (static YAML `id:` and dynamic `SetEndpoint` with an explicit ID), and the empty-ID hash path should keep its current suffix-append tolerance unchanged.

That asymmetry matters because it means "strict unique IDs" is really "strict unique *explicit* IDs" — which is much safer to flip on by default, since it only rejects configs where the operator actually typed a colliding identity.

**3. Detection before production**
The Phase-1 metric below is the answer here — it lets operators see collisions in staging without changing behavior. No integration test can catch an operator's specific misconfig; observability is the right tool.

**4. Version targets**
Defer to maintainers, but the phased shape (observe → opt-in → default-on) is sound. The metric (Phase 1) is the only piece that's both immediately useful and zero-risk, so I'd start there regardless of when the strict flag lands.

## Proposed Phase 1 (the contributor-sized, zero-behavior-change starting point)

Just the observability, no enforcement:

- Add a counter `pixiu_endpoint_id_collision_total{cluster, source}` where `source` ∈ `{static, dynamic_explicit, dynamic_hash}`, incremented wherever a collision currently triggers a suffix/replace (the existing WARN sites in `assembleClusterEndpoints` and `resolveSetEndpointSlotByHash`).
- Keep the existing WARN logs; add a one-line deprecation note pointing at this issue.

This is observable, reversible, and commits us to nothing. If maintainers are OK with the metric (and with OTel as the mechanism, consistent with the snapshot-publish metrics added in #962), I'm happy to take Phase 1 as a small PR and leave the strict-flag phases (2/3) for separate discussion once we have collision data from real deployments.

Does the explicit-vs-empty-ID asymmetry in (2) match how others read the dedup contract? If so I'll write up Phase 1 against the metric mechanism in #962.

--
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: notifications-unsubscribe@dubbo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] RFC: treat duplicate endpoint IDs as a hard configuration error [dubbo-go-pixiu]

Posted by "baerwang (via GitHub)" <gi...@apache.org>.

baerwang closed issue #949: RFC: treat duplicate endpoint IDs as a hard configuration error
URL: https://github.com/apache/dubbo-go-pixiu/issues/949


-- 
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: notifications-unsubscribe@dubbo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org