ai-yang opened a new issue, #739:
URL: https://github.com/apache/rocketmq-dashboard/issues/739
## Affected branch
`rocketmq-studio` at `bbf1b7e0cf25a5065ba049b5450cc8155569f710`
## Description
The Studio topic model and list API expose both `clusterId` and `namespace`,
so a combined list can legitimately contain the same topic name in different
clusters. However, the topic management flow treats `name` alone as the
resource identity:
- the main table uses `rowKey="name"`
- selected rows and batch deletion contain only names
- detail route/consumer caches are keyed only by topic name
- detail endpoints accept only `/{name}`
- the delete request body contains only `{ name }`
- after one delete, local state removes every row with that name
This produces duplicate React row keys and makes detail, selection, and
destructive actions ambiguous across clusters.
## Deterministic reproduction
1. Return two topic rows named `orders`, one with `clusterId=cluster-a` and
one with `clusterId=cluster-b`.
2. Render the Topic 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 `orders` rows disappear because the page
executes:
```ts
previous.filter((item) => item.name !== topic.name)
```
A route-level regression that expects the other cluster's row to remain
failed 5/5 times without timers, network access, or random scheduling.
## Expected behavior
Actions on one topic must not select, cache, remove, or address a same-named
topic in another cluster. The resource identity must therefore include at least
`(clusterId, name)`. `namespace` also exists in `Topic`/`TopicVO`, 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 implementing this across the public management API, could maintainers
confirm the canonical topic identity and request shape?
- 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 requests behave when more than one cluster
matches (for example, reject ambiguity rather than select arbitrarily)?
Once confirmed, an atomic follow-up should cover all of these layers
consistently:
- composite React row keys and selection keys
- detail/cache keys
- single and batch delete payloads
- routes/consumers/detail lookups
- frontend service and backend controller/service/provider interfaces
- compatibility behavior for legacy name-only callers
This issue is intentionally separate from the Consumer Group identity issue
so each API contract can be reviewed and implemented independently. I have a
deterministic red test but have not opened a PR while the
identity/backward-compatibility contract is undecided.
Related work was checked across all states. In particular, #467/#478/#520
contain the maintainer feedback about Namespace support; #677 fixes a LiteTopic
identity issue but not Topic management writes; open #721 handles partial
batch-delete failures while continuing to address topics by name only. None
fixes the 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]
