unbridled-41 opened a new issue, #4906:
URL: https://github.com/apache/rocketmq-dashboard/issues/4906
### 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 defect is in a frontend component and is
reproduced by a component test
browser (for UI issues): not required
```
### Connected RocketMQ Cluster
```
RocketMQ version: not required
access mode: not required
deployment: not required — the metrics API is mocked in the reproduction
```
### Describe the Bug
In Metrics Explorer, changing the range leaves an already-committed custom
PromQL query on the
previous window.
The range control is page-level, and every other path that moves the window
re-runs the committed
custom query. On the base commit `1ef5d860`, all in
`web/src/components/MetricsExplorer.tsx`:
| Path | Behaviour before the fix |
|------|--------------------------|
| refresh button (`:1299-1303`) | `loadAll(...)` **and**
`runCustomQuery(appliedCustomPromql, selectedRange)` |
| instance switch (effect at `:875-883`, re-run at `:882`) |
`runCustomQuery(appliedCustomPromql, selectedRange)` |
| query-history restore (deferred `activateDataSource` at `:852-854`) |
replays both range and custom PromQL |
| **range change (`:701-706`)** | `loadAll(selectedProfile, nextRange)` only
|
```ts
// base commit 1ef5d860, MetricsExplorer.tsx:701-706
const handleRangeChange = (nextRangeId: RangeOption['value']) => {
const nextRange =
RANGE_OPTIONS.find((range) => range.value === nextRangeId) ??
RANGE_OPTIONS[0];
setRangeId(nextRangeId);
void loadAll(selectedProfile, nextRange); // custom panel not re-run
};
```
So with a committed custom query, picking another range re-queried every
profile panel for the new
window while the custom panel kept the samples, the "查询窗口 / Query window"
popover
(`:1136-1137`, fed by `state.query.start/end`) and the export metadata of
the previous one: the
range the operator had just selected disagreed with the panel below it.
### Evidence / Source
Component test added with the fix: it commits `sum(rocketmq_topic_number)`,
clicks `6h`, and asserts
that the custom expression was queried a second time with the 6h window. It
fails on the unfixed
code:
```
$ cd web && npx vitest run src/components/__tests__/MetricsExplorer.test.tsx
-t "re-runs the committed custom query when the range changes"
× re-runs the committed custom query when the range changes
AssertionError: expected [ [ { …(4) } ] ] to have a length of 2 but got 1
Tests 1 failed | 29 skipped (30)
```
Duplicate search: the neighbouring reports are #4264 (closed — the custom
panel after an *instance
switch*), #4188 (closed — the window reverting on an instance switch), #3304
(open — profile panels
freezing when refresh re-runs the custom query; fixed by #3299) and #4569
(series colours). None
covers the range control leaving the custom panel behind, and no open PR
touches
`handleRangeChange`.
### Impact
The custom-query half of the metrics explorer, in both UI languages: an
operator comparing panels
within one screen reads a stale chart, a stale query-window popover and
stale window metadata in the
CSV export of that panel, while the range control above them states the
window they actually picked.
### Expected Behaviour / Acceptance Criteria
- Changing the range re-runs a committed custom query with the new window,
exactly as the refresh
button and an instance switch already do.
- With no committed custom query, the range change behaves as before.
- The profile panels and the custom panel keep their own request
generations, so the added re-run
cannot strand either flow on its spinner (the cross-flow interaction of
#3304/#3299).
- Regression coverage for both points above.
### Corresponding Pull Request
- #4901 — `fix(metrics): re-run the custom query when the range changes`
(test commit `b0ec04b1` adds the second acceptance criterion's assertion;
verified non-vacuous by
simulating the shared-generation freeze, which makes it fail with
`Unable to find an element with the text: 77 messages/s`)
### Additional Context
Found while auditing the paths that re-run the custom query; the
reproduction is the component test
above (metrics API mocked, no cluster, no MySQL, no browser needed).
--
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]
