Wang1rrr opened a new pull request, #4834:
URL: https://github.com/apache/rocketmq-dashboard/pull/4834
<!-- Make sure the base branch is `master`: that is the RocketMQ Studio
trunk. -->
### Which Issue(s) This PR Fixes
Trivial fix, no issue.
### Brief Description
`web/src/pages/instance/message.tsx` and `web/src/pages/instance/topic.tsx`
each carried a private byte formatter for the very same values -
`MessageRecord.size` and the send-payload preview byte counts - and both were
byte-for-byte identical copies of a helper that stops at megabytes:
```ts
const formatBytes = (bytes: number): string => {
if (bytes >= 1048576) return `${(bytes / 1048576).toFixed(2)} MB`;
if (bytes >= 1024) return `${(bytes / 1024).toFixed(2)} KB`;
return `${bytes} B`;
};
```
Three consequences, all visible in the console today:
1. **The unit ladder is truncated.** `web/src/utils/format.ts` already has a
`formatBytes` that scales `B -> KB -> MB -> GB -> TB -> PB`, but these two
copies clamp at MB, so a 5 GiB message body renders as `5120.00 MB` in the
message table and the detail drawer, and a 2 TiB payload preview renders as
`2097152.00 MB`. RocketMQ 5.0 batches and Lite Topic payloads are large enough
for this to be routine rather than theoretical, and the number stops being
readable exactly when an operator needs it.
2. **Two formatters for one field disagree on the base unit.** The shared
one rendered `512.0 B`; the copies render `512 B`. Whichever way the
duplication is resolved, one of the two call sites changes output, so this PR
pins the contract in tests instead of leaving it to chance.
3. **The copies inherit none of the shared guards.** `formatBytes` in
`utils/format.ts` returns `-` for a non-finite value; the copies return `NaN
B`, which is what a size a provider could not resolve renders as today.
This deletes both copies and points all five call sites (2 in `message.tsx`,
3 in `topic.tsx`) at the shared `formatBytes`.
To keep the rendering the two pages already showed for small values,
`formatBytes` now renders the base unit whole - a byte count has no meaningful
fraction, so `512 B` rather than `512.0 B`, while every scaled unit keeps the
caller's precision. That also fixes a latent inconsistency in the promotion
loop: it rounded with `digits` but the base unit now renders with `0`, and a
loop that rounds with a different width than the one it renders can emit a
mantissa of `1024` - `formatBytes(1023.6)` printed `1023.6 B` before and would
print `1024 B` with a naive change, instead of being promoted to `1.0 KB`. The
loop and the return now share one `precision()`.
Note for the reviewer: this touches the same import block of `message.tsx`
as #4829, so whichever of the two lands second needs a one-line rebase. The two
changes are otherwise independent.
### How Did You Test This Change?
```
cd web
npx vitest run src/utils/format.test.ts
src/pages/instance/__tests__/MessagePage.test.tsx
src/pages/instance/__tests__/TopicPage.test.tsx
Test Files 3 passed (3)
Tests 56 passed (56)
npx tsc -b (exit 0)
npx eslint src/utils/format.ts src/utils/format.test.ts
src/pages/instance/message.tsx src/pages/instance/topic.tsx
src/pages/instance/__tests__/MessagePage.test.tsx
(exit 0)
npx prettier --check --end-of-line auto <same files>
All matched files use Prettier code style!
```
(`--end-of-line auto` because this checkout is CRLF while `.prettierrc` pins
`endOfLine: lf`; untouched trunk files fail a plain `--check` here for the same
reason.)
New cases in `web/src/utils/format.test.ts`, next to the existing
`describe('formatBytes')`:
- `keeps scaling past megabytes instead of capping at MB` - `5 * 1024 ** 3
-> '5.0 GB'`, `2 * 1024 ** 4 -> '2.0 TB'`;
- `renders whole bytes because a byte count has no fraction` - `1 -> '1 B'`,
`512 -> '512 B'`, `formatBytes(512, 2) -> '512 B'`, `-2048 -> '-2.0 KB'`;
- `promotes a sub-kilobyte value that only rounds up at whole-byte width` -
`1023.6 -> '1.0 KB'`.
New case in `MessagePage.test.tsx`, driving the real page through a query
and opening the detail drawer:
- `renders a message larger than a megabyte with the matching unit` - a
message with `size: 5 * 1024 ** 3` shows `5.0 GB` in the table row **and** in
the drawer.
Both changes were mutation-checked against the implementations they replace:
- capping the shared unit ladder back to `['B', 'KB', 'MB']` fails 3 format
cases and the new MessagePage case, i.e. the page-level test really does pin
the truncated-ladder bug rather than the helper alone;
- reverting `precision()` to a plain `digits` fails exactly the 2 new
base-unit cases.
Each mutation leaves every pre-existing test green, so the new cases are the
ones carrying the behaviour. All 10 pre-existing `formatBytes` assertions
(`'1024.0 PB'`, `'1 MB'`, `'1.00 GB'`, the boundary promotions, the
invalid-precision bounds) pass unchanged.
### 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` (frontend; Java test naming does not apply)
- [x] New UI text has both Chinese and English entries under `web/src/i18n/`
(no new UI text)
- [x] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks) - no backend change
- [x] New source files carry the ASF license header (no new source files)
- [x] Documentation touched where behaviour changed (README / `docs/` /
in-app help) - none needed; the `formatBytes` doc comment already describes the
1024-based ladder
--
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]
