unbridled-41 opened a new issue, #4907:
URL: https://github.com/apache/rocketmq-dashboard/issues/4907
### Before Creating the Bug Report
- [x] I searched the open **and closed** issues of this repository and
believe this is not a duplicate.
- [x] This is a defect in RocketMQ Studio, not a usage question and not a
defect in another Apache RocketMQ repository.
- [x] I can reproduce this on the `rocketmq-studio` trunk (the branch this
repository's CONTRIBUTING.md points at); the exact commit is stated below.
### Studio Version
```
branch: rocketmq-studio (reproduced on
1ef5d860799ac3fabfcdea942cc4dcc77ded7be6, the base of the fixing PR)
deployed as: built from source
```
### Runtime Environment
```
OS: Ubuntu 22.04 (WSL2)
MySQL: not required — the providers are unit-tested with a mocked cloud
client
browser (for UI issues): not required for the provider half; the rendering
is covered by a component test
```
### Connected RocketMQ Cluster
```
RocketMQ version: Tencent Cloud RocketMQ 5.x and Aliyun RocketMQ 5.x (the
providers these rows come from)
access mode: cloud OpenAPI (Tencent Trocket / Aliyun 20220801), mocked in
the reproduction
deployment: not required — no live cloud instance is contacted
```
### Describe the Bug
For Tencent and Aliyun instances, every row of the consumer-group
queue-progress table reports
`Broker Offset 0` and `Consumer Offset 0` as if they were measurements,
although neither cloud API
exposes per-queue offsets at all — they report the lag per topic.
```java
// server/.../provider/tencent/TencentInstanceProvider.java:533-540 (base
commit 1ef5d860)
rows.add(QueueProgressVO.builder()
.topic(subscription.getTopic())
.broker("topic:" + subscription.getTopic())
.queueId(0)
.brokerOffset(0L) // fabricated: the API has no per-queue
offset
.consumerOffset(0L)
.diffTotal(subscription.getConsumerLag() == null ? 0L :
subscription.getConsumerLag())
.build());
```
```java
// server/.../provider/alibaba/AliyunConverters.java:191-198 and :206-212
(base commit 1ef5d860)
rows.add(QueueProgressVO.builder()
.topic(entry.getKey())
.broker("topic:" + entry.getKey())
.queueId(0)
.brokerOffset(0L)
.consumerOffset(0L)
.diffTotal(ready)
.build());
```
The progress table renders those fields with `offset.toLocaleString()`
(`web/src/pages/instance/consumer.tsx:1296` and `:1306` on the base commit),
so the row shows a real
堆积量 next to two zeros that contradict it, and the reset-offset preview takes
the same zero as the
current consumer offset.
The codebase already has the convention for a value that cannot be
determined: a negative number.
`ConsumerLagResolver.UNKNOWN` is `-1` (its Javadoc names this exact failure
mode, "a fabricated
zero"), the broker itself sends `-1` for an undeterminable gRPC lag,
`onlineInstances` uses `-1`,
the reset-offset preview's own `minOffset`/`maxOffset` are `-1`, and the
console renders a negative
offset as unavailable through `formatOffsetValue` (`consumer.tsx:179-180`)
and the
`targetOffset < 0 || consumerOffset < 0` branch at `:222`. `QueueProgressVO`
had no way to express
"unknown" for an offset, so zero was the only value these providers could
send.
### Evidence / Source
Tests added with the fix; with only the two provider files reverted (the
tests reference the
`QueueProgressVO.UNKNOWN_OFFSET` constant the fix introduces), they fail on
the fabricated zero:
```
$ cd server && mvn -o test
-Dtest='AliyunConvertersLagTest,TencentInstanceProviderTest'
[ERROR]
TencentInstanceProviderTest.getGroupProgressShouldReportUnknownQueueOffsetsTest
<<< FAILURE!
expected: -1L
but was: 0L
[ERROR]
AliyunConvertersLagTest.queueOffsetsShouldBeUnknownWhenOnlyTheTopicLagIsKnownTest
<<< FAILURE!
expected: -1L
but was: 0L
[ERROR] AliyunConvertersLagTest.aggregateRowOffsetsShouldBeUnknownTooTest
<<< FAILURE!
expected: -1L
but was: 0L
Tests run: 55, Failures: 3, Errors: 0, Skipped: 0
```
```
$ cd web && npx vitest run
src/pages/instance/__tests__/ConsumerPage.test.tsx -t "renders an offset the
provider cannot report as unavailable"
× renders an offset the provider cannot report as unavailable
AssertionError: expected [] to have a length of 2 but got +0
Tests 1 failed | 36 skipped (37)
```
The tool contract corroborates the sentinel: `rmq.group.detail` **requires**
`brokerOffset`/`consumerOffset` and declares `minimum: -1` for both
(`server/src/main/resources/tool-catalog/tools/group.yaml:265-266` required,
`:275-280` properties),
so `-1` is the lowest value that schema already accepts.
Related but distinct (checked before filing): #4510 reports the *other*
field of the same method —
Tencent's nullable `ConsumerLag` for `diffTotal` — and its PR #4512 (closed
without merge) left
`.brokerOffset(0L)`/`.consumerOffset(0L)` untouched, as its own diff shows.
Also adjacent, on other
surfaces: #4293 (the topic consumer list publishes the unknown lag as a
value; open) and #4539 (the
Apache reset-offset preview clamped an unknown lag; closed).
### Impact
Monitoring data that contradicts itself in the same row, for every
Tencent/Aliyun consumer group:
operators see `Broker Offset 0` / `Consumer Offset 0` where the platform has
no data, and any
downstream consumer of the JSON that reads the offsets (including the
reset-offset preview) treats
the fabricated zero as the current position.
### Expected Behaviour / Acceptance Criteria
- `brokerOffset` and `consumerOffset` of a cloud progress row that carries
no queue offsets report
the unknown sentinel (a negative value), not zero.
- `diffTotal`, the real per-topic lag, is unchanged.
- The progress table renders such an offset as unavailable rather than as a
number.
- The Apache provider's real offsets and the `rmq.group.detail` output
schema (which requires these
properties) keep working.
### Corresponding Pull Request
- #4902 — `fix(group): report cloud queue offsets as unknown instead of zero`
### Additional Context
Found while auditing the consumer-progress rows against what the cloud APIs
actually expose. The
pseudo-broker name (`topic:<topic>`), the `queueId = 0` of these aggregate
rows and the summary cards
that count rows as queues are deliberately out of scope: those are
presentation decisions, not
fabricated measurements.
--
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]
