ai-yang opened a new issue, #740: URL: https://github.com/apache/rocketmq-dashboard/issues/740
## Affected branch `rocketmq-studio` at `bbf1b7e0cf25a5065ba049b5450cc8155569f710` ## Description The Studio consumer-group model and list API expose `clusterId` and `namespace`, so the same group name can appear in multiple clusters. The management flow nevertheless treats `name` alone as the identity: - the main table uses `rowKey="name"` - selection and batch delete contain only group names - subscription/progress/detail caches are keyed only by name - detail, progress, subscription, reset-offset, and delete APIs omit cluster/namespace identity - after deleting one row, local state removes every group with the same name - creating a group also replaces every existing row with the same name This makes row rendering, details, progress, selection, reset, and destructive actions ambiguous across clusters. ## Deterministic reproduction 1. Return two consumer groups named `remote-cg`, one in `cluster-a` and one in `cluster-b`. 2. Render the Consumer Group page and confirm that both rows are present. 3. Delete the first row and confirm the dialog. 4. Observe the remaining table rows. On the unmodified branch, both rows disappear because the page filters local state by name alone. A route-level regression that expects the group from the other cluster to remain failed 5/5 times without timers, network access, or random scheduling. ## Expected behavior An action on one consumer group must not select, cache, remove, reset, or address a same-named group in another cluster. The identity must therefore include at least `(clusterId, name)`. `namespace` also exists in `ConsumerGroup`/`ConsumerGroupVO`, but earlier maintainer feedback indicates that Namespace is not currently a generally supported Studio capability, so it should not be assumed unconditionally. ## Contract question / proposed scope Before changing the management API, could maintainers confirm the canonical consumer-group identity and compatibility behavior? - Is the current identity at least `(clusterId, name)`? - When Namespace capability is available, should this extend to `(clusterId, namespace, name)`? - How should legacy name-only calls behave when more than one cluster matches? Once confirmed, an atomic follow-up should align: - React row/selection keys - subscription, progress, and detail caches - detail/progress/subscription routes - single/batch delete and reset-offset payloads - frontend service and backend controller/service/provider interfaces - compatibility behavior for legacy name-only calls This issue is intentionally separate from the Topic identity issue. I have a deterministic red test, but no implementation PR is appropriate until the public API identity and backward-compatibility contract are confirmed. Related work was checked across all states. #638 connects the current group management path but retains name-only caches and requests; #677 only fixes LiteTopic identity; open #724 adds subscription consistency diagnostics while continuing to key by group name. #467/#478/#520 contain the maintainer feedback about Namespace support. None fixes this cross-cluster ambiguity, and none is assigned to this issue. -- 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]
