unbridled-41 opened a new pull request, #4604:
URL: https://github.com/apache/rocketmq-dashboard/pull/4604
Fixes #4600.
## Problem
A failed consumer-progress request was rendered as a legitimate empty
result: the progress tab asserted that the group is not online with zero
brokers and zero queues, and the health tab kept reporting a healthy group
although the queue progress it summarizes was never read.
## Evidence
Regression test added with this PR
(`web/src/pages/instance/__tests__/ConsumerPage.test.tsx` → `does not report a
failed progress load as an offline consumer group`), run against the pre-fix
code (baseline `origin/master` = d50ffecc):
```
× does not report a failed progress load as an offline consumer group 7772ms
Tests 1 failed | 32 skipped (33)
```
The first assertion that fails is the empty-state claim `消费组不在线，暂无队列进度数据`,
which the test finds in the progress panel of a group whose progress request
rejected.
## Root cause and fix
`loadProgress` swallowed the failure without recording it:
```ts
try {
const progress = await getConsumerProgress(groupName, selectedInstanceId
|| undefined);
setProgressByGroup((prev) => ({ ...prev, [cacheKey]: progress }));
} catch {
if (!silent) message.error(t('consumer.fetchProgressFailed', { name:
groupName }));
}
```
so the render fell back to `progressByGroup[key] ?? []` and the same empty
array fed both the table's `消费组不在线` empty text (with `总 Broker 数: 0` / `总 Queue
数: 0` / `总堆积: 0`) and `analyzeConsumerGroupHealth(group, subscriptions, [])`,
which sees no queues and reports no risk. The subscription loader in the same
file already keeps `subscriptionErrorByGroup` for exactly this reason; the fix
adds the missing counterpart per instance and group, clears it on a successful
read, and uses it to state that the progress could not be loaded (progress tab)
and that the diagnosis does not include queue progress (health tab).
## Priority and scoring
PRIORITY 71 = impact 27 + scope 11 + reproducibility 18 + maintenance value
15.
- Impact 27: on a transient broker/network failure the operator is told the
group is offline *and* healthy with zero lag, which is the opposite of what a
failing offset query usually indicates.
- Scope 11: every consumer-group detail view whose progress request fails,
including silently during the 2s auto-refresh.
- Reproducibility 18: deterministic, covered by the added test.
- Maintenance value 15: the error-versus-empty distinction already exists in
the same file for subscriptions.
FIX_CONFIDENCE 92: one keyed flag next to the existing subscription flag, no
API change, module suite green.
## Tests
- Red (baseline source + new test): `Tests 1 failed | 32 skipped (33)` on
the empty-state assertion.
- Green: `npx vitest run --maxWorkers=2
src/pages/instance/__tests__/ConsumerPage.test.tsx -t "failed progress load"` →
**1 passed**; the same test, the diagnostics-race test and the client-stack
test each pass in isolation.
- Module suite note: running the whole `ConsumerPage.test.tsx` file in this
sandbox has one or two failures that are load-dependent; the pristine baseline
file (32 tests, without this PR's test) fails the same way in a full run and
every affected test passes in isolation. Details and evidence are in the
verification comment below.
- Full web suite: see the verification comment below.
- `npx tsc -b` clean; `npx eslint` on both changed files → no output.
## Risk
Low. The added state only changes what is rendered when the progress read
failed; a successful read clears the flag and renders exactly as before. The
health check itself (`analyzeConsumerGroupHealth`) is unchanged — it still
receives the loaded data, and the new notice only states that queue progress is
missing.
--
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]
