3219378872 opened a new issue, #5101:
URL: https://github.com/apache/rocketmq-dashboard/issues/5101
## Before Creating the Bug Report
- [x] I searched the open and closed issues and pull requests and did not
find a matching report.
- [x] This is a defect in RocketMQ Studio's existing group-detail tool.
- [x] The exact source revision is stated below.
## Studio Version
`rocketmq-studio` at `a562601` (built from source).
## Runtime Environment
Linux, OpenJDK 21. Reproduced locally by running the unchanged production
DTO projection and Jackson serialization; no database, live broker, or browser
is needed to reproduce the information loss.
## Connected RocketMQ Cluster
No live cluster used for the local reproduction. Input uses the same
`QueueProgressVO` produced by `RocketMQMetadataProvider.getGroupProgress`: each
queue has a Topic, broker name, queue id and offsets.
## Describe the Bug
`rmq.group.detail` returns queue-level consumer progress, but
`GroupDetailOutput.QueueProgress.from()` drops `QueueProgressVO.topic`. Without
the optional `topicName` filter, a group subscribing to multiple Topics can
return several rows with the same broker and queue id and no way to tell which
Topic each row describes.
The REST progress VO already retains the Topic; the information disappears
specifically in the tool projection used by MCP and `rmqctl group detail`.
## Steps to Reproduce
1. Prepare two `QueueProgressVO` rows: `orders / broker-a / queue 0` and
`payments / broker-a / queue 0`.
2. Give both rows broker offset 20, consumer offset 8, lag 12.
3. Call the existing `GroupDetailOutput.from(...)` with those rows and a
null topic filter, then serialize `output.progress()` with Jackson.
The unchanged production code returns:
```json
{"totalLag":24,"queues":[
{"broker":"broker-a","queueId":0,"brokerOffset":20,"consumerOffset":8,"lag":12},
{"broker":"broker-a","queueId":0,"brokerOffset":20,"consumerOffset":8,"lag":12}
]}
```
The two projected records are equal even though their source queues belong
to different Topics. This is not dependent on equal lag values; unequal values
would still be impossible to attribute to the correct Topic from the returned
rows.
## What Did You Expect to See?
Each returned queue should preserve its Topic identity along with broker and
queue id, so an operator or agent can identify which Topic is accumulating
messages in one group-detail call.
## What Did You See Instead?
The tool output and its declared `group.yaml` output schema have no Topic
field on `progress.queues[]`. The caller must issue additional per-Topic
queries to infer the association.
## Additional Context
Relevant sources:
-
`server/src/main/java/org/apache/rocketmq/studio/ops/ai/tool/contract/group/GroupDetailOutput.java`:
`QueueProgress` and `QueueProgress.from()`.
-
`server/src/main/java/org/apache/rocketmq/studio/instance/group/QueueProgressVO.java`:
source `topic` field.
- `server/src/main/resources/tool-catalog/tools/group.yaml`:
`rmq.group.detail` output schema, `progress.queues`.
Proposed narrow fix: preserve `topic` in the existing projection and declare
it in the matching output schema, with a regression using two Topics on the
same broker/queue id and retaining coverage for topic filtering and unknown
offsets/lag. No new tool or request parameter is needed.
## Are You Willing to Submit a Pull Request?
- [x] Yes.
--
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]
