unbridled-41 opened a new pull request, #4901:
URL: https://github.com/apache/rocketmq-dashboard/pull/4901
<!-- Base branch: `rocketmq-studio`, the RocketMQ Studio trunk. -->
### Which Issue(s) This PR Fixes
- No issue tracks this defect; the searches under *Duplicate check* found
none.
### Brief Description
After committing a custom PromQL expression, changing the range left the
custom panel on the
previous window.
The range control is page-level, and every other path that moves the window
re-runs the committed
custom query:
| Path | Behaviour on the base commit `1ef5d860` |
|------|------------------------------------------|
| refresh button (`web/src/components/MetricsExplorer.tsx:1354-1357`) |
`loadAll(...)` **and** `runCustomQuery(appliedCustomPromql, selectedRange)` |
| instance switch (`:878-880`) | `loadAll(...)` **and**
`runCustomQuery(appliedCustomPromql, selectedRange)` |
| query-history restore (`:823-824` via `activateDataSource`) | replays both
range and custom PromQL |
| **range change (`:701-706`)** | `loadAll(selectedProfile, nextRange)` only
|
```ts
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 `24h` re-queried every profile
panel for the new window
while the custom panel kept the samples, the "查询窗口 / Query window" popover
(`:1189-1190`, fed by `state.query.start/end`) and the export metadata of
the old one — the range
the operator had just selected disagreed with the panel under it.
### Fix
Re-run the committed custom query with the next range, mirroring the refresh
handler. Because
`runCustomQuery` is defined below the old position of `handleRangeChange`,
the handler moves below
it (no behaviour change beyond the added call).
### Evidence (pre-fix, on the base commit `1ef5d860`, new test kept and only
`MetricsExplorer.tsx` reverted)
```
$ 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)
```
The test commits `sum(rocketmq_topic_number)` at the default window, clicks
`6h`, and asserts the
custom expression was queried twice with the second call carrying the 6h
window. Pre-fix only the
profile panels were re-queried, so the custom call count stayed at 1.
### Duplicate check
Searched issues and PRs (open and closed) for `custom query range`, `query
window`, `range change`,
`appliedCustomPromql`, `MetricsExplorer`: #4264 (closed) is the
instance-switch case that the
`:878-880` path already handles, and no issue or PR covers the range
control. Of the open PRs
touching this file — #4836 (legend identities), #4570 (series colours), and
my own #4888/#4892
(language identity, restore rollback) — none touches `handleRangeChange` or
the custom re-run
paths.
### Scoring (AGENTS.md)
`PRIORITY` = impact 18 + reach 12 + reproducibility 18 + maintenance value
12 = **60**;
`FIX_CONFIDENCE` = **88**. (Impact: a panel that silently keeps a different
time window than the
one the operator selected, including the window metadata it exports; reach:
the custom-query half
of the metrics explorer; reproducibility: pinned by a deterministic
component test.)
### How Did You Test This Change?
```
$ cd web && npx vitest run src/components/__tests__/MetricsExplorer.test.tsx
Test Files 1 passed (1)
Tests 30 passed (30)
$ cd web && npx vitest run src/components
Test Files 8 passed (8)
Tests 88 passed (88)
$ cd web && npx tsc -b && npx eslint src/components/MetricsExplorer.tsx
src/components/__tests__/MetricsExplorer.test.tsx
(no output, exit 0)
```
### Checklist
- [x] One coherent change; unrelated modifications are not bundled in
- [x] Commit subject follows Conventional Commits (`fix:`)
- [x] Tests added for the changed behaviour
- [x] New UI text: none
- [x] Architecture constraints stay green (no server change)
- [x] New source files: none
- [x] Documentation: not touched
### Risk
Low. The added call is the same one the refresh button makes, with the range
the operator just
picked instead of the previous one; a custom query that is not committed
(`appliedCustomPromql`
empty) is untouched, and the profile-panel load order is unchanged. The only
extra effect is a
history entry per range change, which is what a refresh already does.
--
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]
