Frun1na opened a new pull request, #6793:
URL: https://github.com/apache/rocketmq-dashboard/pull/6793
### Which Issue(s) This PR Fixes
- Fixes #6790
### Brief Description
The demo messages did not satisfy the message contract.
`web/src/mock/messages.ts:18` declared its own `MessageRecord` instead of the
endpoint's, and that copy had no `brokerName`, `queueId` or `queueOffset` — all
three are required in `web/src/api/message.ts:9-11`.
`web/src/services/messageService.ts:52` cast the fixtures over the mismatch
(`mockMessages as unknown as MessageRecord[]`), which is why neither `tsc` nor
the suite could see it.
The detail panel reads two of them directly
(`web/src/pages/instance/message.tsx:1041` and `:1047` print
`selectedMsg.brokerName ?? '-'` and `selectedMsg.queueOffset ?? '-'`), so in
Mock mode every message showed `-` for **Broker** and **Queue Offset** while
the rest of the panel was populated.
The fixture is now declared as the contract type, its 22 messages carry the
three fields (the broker name follows the message's own `storeHost`, so a
detail view names a stable broker per message), and the cast that hid the drift
is gone — `tsc` checks the fixtures against `web/src/api/message.ts` from now
on.
User-visible change: in Mock mode the message detail shows a Broker and a
Queue Offset instead of two placeholders.
### Other consumers
`git grep "from '.*mock/messages'"` returns exactly one importer,
`web/src/services/messageService.ts`, which was checked surface by surface:
- `queryMessages` — the reported path; the fixtures and the cast are fixed
here.
- Its `key` filter (`:44`) — typing the fixture surfaced that it read
`m.key.includes(...)`, and the contract types `key` as `string | null`, so a
keyless message would have thrown instead of not matching. It now reads `(m.key
?? '').includes(...)`, which matches the endpoint's behaviour (a key query
never returns a message without that key). No current fixture message is
keyless, so this is a type-safety fix, not a second reproduction.
- `queryMessagePage` — filters through the same `queryMessages`, so it
inherits both changes.
- `getMessageTrace` — reads `mockMessageTraces`, whose `TraceRecord` was
already checked against `api/message.ts` by the same type assignment and had no
mismatch; untouched.
- `web/src/api/message.ts:3` states "Matches mock/messages.ts", which was
the property that had been lost; it holds again now that the fixture uses that
type.
- `MessageProperties` / `QueueBrowser` consume the API type (not the
fixture), so they were only ever affected through the records `messageService`
returned.
### How Did You Test This Change?
```
$ ./wb test --filter src/services/messageService.test.ts
✗ npx vitest run src/services/messageService.test.ts --maxWorkers=1
--fileParallelism=false
Expected: "string"
Received: "undefined"
❯ src/services/messageService.test.ts:58:34
Test Files 1 failed (1)
Tests 1 failed | 12 passed (13)
$ ./wb test
✓ 1.3s npx eslint src/mock/messages.ts
src/services/messageService.test.ts src/services/messageService.ts
✓ 0.6s npx prettier --check src/mock/messages.ts
src/services/messageService.test.ts src/services/messageService.ts
✓ 72.7s npx vitest related --run src/mock/messages.ts
src/services/messageService.test.ts src/services/messageService.ts
Test Files 5 passed (5)
Tests 109 passed (109)
✓ 4.0s npx tsc -b
```
The new test fails without the fix:
```
# web/src/mock/messages.ts and web/src/services/messageService.ts reverted,
the test kept
$ ./wb test --filter src/services/messageService.test.ts
✗ npx vitest run src/services/messageService.test.ts --maxWorkers=1
--fileParallelism=false
Expected: "string"
Received: "undefined"
Test Files 1 failed (1)
Tests 1 failed | 12 passed (13)
```
The assertion goes red because it asks a Mock message row for `brokerName`
as a string; with the fixtures reverted the field is absent from the record, so
it is `undefined` and the failure reads exactly `Expected: "string" / Received:
"undefined"` — the same absence that made `message.tsx:1041` print `-`. The 12
sibling tests in the file stay green, which is what shows the assertion pins
the fixture's contract fields rather than the mock pipeline as a whole. `tsc
-b` is also part of the fix's evidence: with the fixture typed by the contract,
the old `m.key.includes(...)` no longer compiles.
### Checklist
- [x] One coherent change; unrelated modifications are not bundled in
- [x] Commit subject follows Conventional Commits (`feat:` / `fix:` /
`refactor:` / `chore:` / `docs:` / `perf:`)
- [x] Tests added or updated for non-trivial changes, test methods named
`...Test`
- [ ] New UI text has both Chinese and English entries under `web/src/i18n/`
- [ ] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks)
- [ ] New source files carry the ASF license header
- [ ] Documentation touched where behaviour changed (README / `docs/` /
in-app help)
--
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]
