unbridled-41 opened a new issue, #4749:
URL: https://github.com/apache/rocketmq-dashboard/issues/4749
### Studio Version
branch: rocketmq-studio
git commit id: cd448e17f14b4bd6e6d4ade87300caf19ca91bc2
### Problem
A consumer group that has never connected is reported as "connection
inventory unavailable" in the group list, although the same group is reported
as simply offline (0 online instances) in its detail view. Two answers, same
group, same view.
Chain:
- The list path resolves the connection set through
`RocketMQMetadataProvider.resolveConsumerConnection`
(`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQMetadataProvider.java:382-397`),
which grades failures with `isGroupNotOnline` (`:746-770`) and sets
`vo.setOnlineInstances(connection.available() ? instances.size() : -1)`
(`:335`).
- `isGroupNotOnline` knows `CONSUMER_NOT_ONLINE` (typed and textual) and
`BROADCAST_CONSUMPTION`, but not `TOPIC_NOT_EXIST`: the same file documents the
case at `:777-783` — "examineConsumeStats / examineConsumerConnectionInfo
locate brokers through the {%RETRY%<group>} topic route, but 5.x POP consumer
groups only get their retry topic created once a retry actually happens, so
brand-new groups fail with CODE 17" — and it pre-creates the retry topic for
that reason in the progress and subscription paths (`ensureRetryTopicExists` at
`:638`/`:691`), which the list path intentionally does not do per group.
- The detail path grades the same exception as offline:
`RocketMQAdminClientImpl.isConsumerNotOnline` (`:244-259`) accepts
`TOPIC_NOT_EXIST` with a `%RETRY%` message (`:254-256`) and falls back to the
proxy resolver, leaving `onlineInstances` at its `0` default
(`ConsumerGroupVO.java`).
Trigger (deterministic): create a consumer group (Studio writes only the
broker-side group config; the retry topic appears on first consumer
registration), then open the group list before any consumer connects. The list
shows the connection inventory as unavailable; opening the group reports 0
online instances.
### Evidence
- List path: `RocketMQMetadataProvider.java:335` (the `-1`), `:387` (the
`isGroupNotOnline` call), `:746-770` (missing grading), `:777-783` (the file's
own description of the CODE 17 case).
- Detail path: `RocketMQAdminClientImpl.java:244-259`, reached from
`:150-152`.
- Web impact: `web/src/utils/consumerConnections.ts:28-35` renders `-1` as
the "unknown" label, and `web/src/utils/consumerGroupDiagnostics.ts:302-320`
turns `onlineInstances < 0` into a `CONNECTION_STATUS_UNKNOWN` warning
("客户端连接状态不可用") which is an `else if` branch, so the
`NO_ACTIVE_CLIENTS_WITH_LAG` critical finding ("有堆积但无在线客户端") never runs for
such a group.
- Regression test added with this report
(`RocketMQMetadataProviderTest.listConsumerGroupsShouldGradeAMissingRetryTopicRouteAsOfflineTest`),
failing on cd448e17:
```
[ERROR] ...listConsumerGroupsShouldGradeAMissingRetryTopicRouteAsOfflineTest
-- Time elapsed: 0.020 s <<< FAILURE!
but was: -1
[ERROR] Tests run: 45, Failures: 1, Errors: 0, Skipped: 0
```
### Impact
A brand-new or long-idle group is presented as having an unreadable
connection inventory, with a warning that sends the operator to check
Broker/Proxy connectivity for a state that is simply "no client is connected
yet". For a group that already has backlog, the false warning also replaces the
genuinely actionable critical diagnostic that says the group has accumulated
messages with no online client. The group list CSV export prints the same
"unknown" value.
### Expected behavior
A group whose retry topic has no route yet is graded as offline, exactly
like the detail path: `onlineInstances` is 0 with an empty instance list, not
-1.
### Related work
- #4544 (merged, `cd448e17`) introduced the three-state resolution this
report aligns; it graded `CONSUMER_NOT_ONLINE`/`BROADCAST_CONSUMPTION` but not
the CODE 17 case the same commit's comments describe.
- #4006 (open) — client connection listing returns 502 when every group is
offline; that is `RocketMQClientProvider`, a different endpoint and a different
symptom (error instead of a wrong value).
- #4463 (open) — producer connection scans returning partial inventories;
producer side, not the consumer group inventory.
#
## PR
Fix: #4750.
This PR targets the development trunk `rocketmq-studio`. GitHub interprets
closing keywords only for pull requests that target the repository default
branch, and this repository default branch is still `master`, so merging the PR
will not close this issue automatically — it needs to be closed by hand.
--
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]
