unbridled-41 opened a new issue, #4611:
URL: https://github.com/apache/rocketmq-dashboard/issues/4611
### Studio Version
branch: master
git commit id: d50ffecc9d7e8f8f46da64198831bd7952e6974e
### Problem
In `web/src/utils/clientConnectionDiagnostics.ts` the resource-level summary
table never sees the per-connection issues (unknown protocol / language /
version, invalid connection time, duplicate records), so every resource row
renders `issueCount: 0` and `status: healthy` even when the issue list directly
below is full of findings about that resource's connections.
Root cause — two different key shapes for the same concept inside one file:
- Per-connection issue producers set `resource` to the bare normalized name:
- `addUnknownFieldIssues` (`:292`): `const resource =
normalizeText(connection.groupOrTopic);` — used for `UNKNOWN_PROTOCOL`
(`:307`), `UNKNOWN_LANGUAGE` (`:325`), `UNKNOWN_VERSION` (`:343`),
`INVALID_CONNECTION_TIME` (`:361`).
- `addClientIdIssues` duplicate path (`:277`): `resource` from
`identity.split('|')` — also the bare name.
- Resource summaries match issues with `issuesForResource(issues, resource)`
(`:474-475`) where the lookup key is the type-qualified
`${group.type}:${group.resource}` (`addResourceIssues:378`,
`buildResourceSummaries:483`, via `resourceKey:164-165`).
So `issues.filter((issue) => issue.resource === resource)` compares
`my-group` against `Consumer:my-group` and never matches.
`buildResourceSummaries` (`:477-513`) then computes `status:
resourceSeverity([])` → `healthy` and `issueCount: 0` for every resource that
has no *resource-level* issue — even when its connections carry warnings.
Trigger (deterministic, unit-testable): one consumer group `cg-order` with a
single client reporting `protocol: 'Custom'` and `version: '-'`. The issues
panel lists `UNKNOWN_PROTOCOL` (warning) and `UNKNOWN_VERSION` (warning) for
that connection; the resource row for `cg-order` shows 状态 healthy and 问题数 0.
### Evidence
- `web/src/utils/clientConnectionDiagnostics.ts:292,307,325,343,361,277` —
bare-name resource keys.
- `web/src/utils/clientConnectionDiagnostics.ts:378,483` —
`${group.type}:${group.resource}` lookup keys; `:474-475` equality filter.
- Consumer: `web/src/pages/cluster/clients.tsx:518-527` renders
`record.status` as the colored health tag and `:588-594` renders `issueCount`
as a gold(>0)/green(0) tag in the 资源维度 table (`:869
dataSource={clientDiagnostics.resources}`).
- Existing tests only assert resource summaries for *resource-level* issues
(`MIXED_PROTOCOL_RESOURCE` etc. in
`web/src/utils/clientConnectionDiagnostics.test.ts:161-178`), which is why the
mismatch was never caught: those producers happen to use the qualified key.
### Impact
The 诊断 tab's resource table is the triage surface: an operator scanning it
sees all-green rows with zero issue counts while the connection-level issues
panel simultaneously reports unknown protocols/versions for those very
resources. The per-resource rollup — the whole point of
`buildResourceSummaries` — silently under-reports.
### Expected behavior
Per-connection issues attribute to their resource summary: the `cg-order`
row shows warning status and issue count 2 (or the matching keys are unified in
one place), so the resource table and the issues panel agree.
### Related work
- #4543 / PR #4544 (consumer connection lookup failures reported as zero
online clients) — different layer: provider data grading, not the diagnostics
rollup.
- #4502 / PR #4503 and PR #4534 — constrain diagnostics to registered
NameServers; unrelated to key matching.
### PR
Fix incoming.
--
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]
