X-LightYear opened a new issue, #5108:
URL: https://github.com/apache/rocketmq-dashboard/issues/5108
### Before Creating the Bug Report
- [x] Reproduced on the documented `rocketmq-studio` trunk at
`a562601d0971001c1cd3b888a9f2664b6ef77811`.
- [x] This is a RocketMQ Studio provider defect, not an upstream RocketMQ
broker defect.
- [x] Searched open and closed Issues and PRs for LiteTopic lag,
`liteTopicLagMap`, Aliyun consumer-group progress, and group-progress rows; no
duplicate was found.
### Problem
Aliyun's `GetConsumerGroupLag` response exposes LiteTopic backlog in
`data.liteTopicLagMap`, but Studio's `AliyunConverters.toQueueProgressRows`
only reads `data.topicLagMap`. A consumer group that consumes only LiteTopics
therefore returns no progress row at all, even though the provider received a
valid lag measurement.
### Production path
`GET /api/groups/{name}/progress?instanceId=...`
→ `MetadataService.getGroupProgress`
→ `AliyunInstanceProvider.getGroupProgress`
→ Aliyun `GetConsumerGroupLag`
→ `AliyunConverters.toQueueProgressRows`
The Aliyun SDK model used by the current code has
`Data.getLiteTopicLagMap()` with `DataLiteTopicLagMapValue.getReadyCount()`.
### Reproduction
Use a valid Aliyun consumer-group-lag response containing:
```json
{
data: {
liteTopicLagMap: {
lite-orders: { readyCount: 7 }
}
}
}
```
Open the consumer group's progress view or call the progress endpoint.
### Expected behavior
The progress result contains a row for `lite-orders` with `diffTotal=7`. The
existing unknown-offset convention remains applicable because Aliyun reports
topic-level lag rather than broker queue offsets.
### Actual behavior
The result is an empty list. The LiteTopic backlog is silently omitted from
the consumer-group progress response.
### Deterministic regression evidence
Added `AliyunConvertersLagTest.liteTopicLagShouldProduceAProgressRowTest` in
the local validation worktree. On the current production code it fails
deterministically:
```text
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0
AliyunConvertersLagTest.liteTopicLagShouldProduceAProgressRowTest
Expected size: 1 but was: 0
```
The failing assertion is the exact user-visible contract: a valid LiteTopic
lag entry must produce one progress row.
### User impact
Operators monitoring Aliyun consumer groups can miss LiteTopic backlog
entirely. This can make the progress table, diagnostics, and any downstream
backlog aggregation appear empty or incomplete for groups whose subscriptions
include LiteTopics.
### Proposed scope
Merge the Aliyun LiteTopic lag map into the existing topic-level progress
conversion without creating a duplicate aggregate row when either breakdown is
present. Preserve the existing offset-unknown sentinel and ordinary topic
behavior.
--
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]
