tju-yxq opened a new issue, #5264:
URL: https://github.com/apache/rocketmq-dashboard/issues/5264
## Problem
The `Frontend Build (Node 20)` job fails at the typecheck step on **every**
pull request targeting `rocketmq-studio` — regardless of author and regardless
of which files the PR touches — because the trunk's own
`MetricsExplorer.test.tsx` does not typecheck. The same error also fails
`Frontend Docker Build`. With the job permanently red, a genuine type
regression in a PR is indistinguishable from the pre-existing failure.
## What did you do (steps to reproduce)?
1. Check out a clean `rocketmq-studio` (verified at `a460673f`).
2. Install dependencies and run the typecheck that the build runs first:
```
cd web && npm ci && npx tsc -b --force
```
3. Alternatively, open any PR against `rocketmq-studio` and look at its
`Frontend Build (Node 20)` / `Frontend Docker Build` checks.
## What did you expect to see?
`tsc -b` exits 0 on an unmodified trunk checkout, and the frontend CI jobs
are green for PRs that do not break anything.
## What did you see instead?
```
src/components/__tests__/MetricsExplorer.test.tsx(516,38): error TS2353:
Object literal
may only specify known properties, and 'query' does not exist in type '{
cluster: string;
node_id: string; }'.
```
The command exits non-zero and both frontend jobs fail. Every `pull_request`
CI run on 2026-10-01 (38 runs, from many different contributors and branches)
shows this failure; the error is in a test file most of those PRs never touch.
## Root cause
Three code facts in `web/src/components/__tests__/MetricsExplorer.test.tsx`:
- The fixture is an untyped literal (around line 86):
```ts
const metricData = {
resultType: 'matrix',
series: [
{
labels: { cluster: 'prod', node_id: 'broker-a' },
```
so TypeScript infers `labels` as the concrete object type `{ cluster:
string; node_id: string }`.
- The deferred is typed from that inference (around line 470):
```ts
const customQuery = createDeferred<typeof metricData>();
```
which locks `customQuery.resolve(...)` to the narrowed literal type.
- The custom-query fixture adds a label the base fixture never had (around
line 516):
```ts
customQuery.resolve({
...metricData,
series: [
{
...metricData.series[0],
labels: { cluster: 'prod', query: 'custom' },
```
The API contract is `MetricSeries.labels: Record<string, string>`
(`web/src/api/metrics.ts`, around line 60), so a `query` label is perfectly
valid at runtime and against the contract — but the excess-property check runs
against the *inferred* literal type, not the contract, and rejects the unknown
`query` key.
## Expected behavior
- `cd web && npx tsc -b` exits 0 on a clean `rocketmq-studio` checkout.
- `Frontend Build (Node 20)` and `Frontend Docker Build` reach the vite
build step instead of failing at typecheck.
- The 35 existing `MetricsExplorer.test.tsx` tests keep passing unchanged.
- No runtime behavior of the component or the tests changes.
## Acceptance criteria
- [ ] Regression proof: on unmodified `rocketmq-studio`, `cd web && npx tsc
-b --force` reports the TS2353 error above; with the fix it exits 0 with no
errors anywhere in the project.
- [ ] `cd web && npm test -- MetricsExplorer.test.tsx --run` still passes
all 35 tests.
- [ ] The fix changes only the fixture's typing (no test logic, no component
code).
- [ ] PRs against `rocketmq-studio` no longer fail the two frontend jobs at
the typecheck step.
## Environment
- Branch `rocketmq-studio` at `a460673f` (2026-10-01).
- Node 20, TypeScript from the repository's devDependencies (as CI runs it).
- Files involved: `web/src/components/__tests__/MetricsExplorer.test.tsx`,
`web/src/api/metrics.ts`.
## Other information
The trunk `push`-event CI workflow itself currently reports
`startup_failure`, which is why a type error of this kind can land on trunk
without being caught at merge time. This report covers only the typecheck
error; the backend `binary-license-gate` failure on
`error_prone_annotations-2.49.0.jar` is a separate breakage.
## Duplicate check
Searched open and closed issues and PRs for `MetricsExplorer`, `typecheck`,
`TS2353`, and `frontend build`. The existing MetricsExplorer issues (#3304,
#4655, #4781, #4906, #4264, #4188, #2492, #4569, #4893) all describe runtime
behaviors (spinners, series mixing, range handling), none the compile-time
failure. No issue or PR reports the broken frontend typecheck.
--
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]
