Frun1na opened a new pull request, #6775:
URL: https://github.com/apache/rocketmq-dashboard/pull/6775
### Which Issue(s) This PR Fixes
- Fixes #6773
### Brief Description
`InstanceVO` declared the resource-count sentinel as `@Builder.Default
private boolean resourceCountsAvailable = true;` (`InstanceVO.java:47`), but
`topicCount` and `consumerGroupCount` are not columns on the row:
`MybatisPlusInstanceRepository.toVO` never populates them, so they exist only
on the values `InstanceService.listInstances` resolves per request —
`applyCounts` sets the flag `true` and `clearCounts` sets it `false`
(`InstanceService.java:206-216`).
Every other value therefore shipped the "counts can be trusted" default over
read-back zeros. `POST /api/instances/create` (`InstanceService.java:230`)
never resolves counts and answers with what `save` produced; `POST
/api/instances/update` (`InstanceService.java:627`) answers with
`copyOf(existing)`, and `existing` comes from `findById`, so it carries the
same zeros. Serialised, both report `topicCount: 0, consumerGroupCount: 0,
resourceCountsAvailable: true`.
`docs/api-spec.md` §3.1 defines the flag as "上面两个计数是否可信；`false`
表示未请求或解析失败，此时不应把 `0` 当成真实数量", and §3.2 / §3.3 declare the same `Instance`
object as their response. A caller honouring that contract reads a fabricated
"0 topics, 0 consumer groups" for an instance whose cluster may hold hundreds.
The default is now `false`, so only the path that measures the counts can
claim them. `applyCounts` and `clearCounts` already set the flag explicitly on
that path, so `GET /api/instances` is unchanged — this is the same "unknown is
not zero" rule the list endpoint already follows, applied to the two write
responses that were left on the default.
User-visible change: the create and update responses now report
`resourceCountsAvailable: false` instead of presenting unmeasured zeros as
measured.
### Other consumers
`git grep resourceCountsAvailable` returns five surfaces; each was checked:
- `server/.../instance/InstanceService.java:206-216` — the measuring path.
`applyCounts` sets `true`, `clearCounts` sets `false`; both are explicit, so
the new default cannot change them. Unchanged, covered by the existing
`listInstancesMarksCloudCountsUnavailableWhenProviderFails`,
`listInstancesKeepsCloudCountsAvailableWhenProviderReturnsEmptyLists` and
`listInstancesWithoutCountsSkipsProviderLookupsTest`.
- `server/.../instance/InstanceVO.java:47` — fixed here.
- `server/.../instance/MybatisPlusInstanceRepository.java` — no reference to
the field or to either count; the repository cannot populate them, which is why
the default was the only thing the write responses had to go on.
- `web/src/api/instance.ts:47` — the type already declares the field
optional (`resourceCountsAvailable?: boolean`), so the two responses stay
inside it.
- `web/src/pages/instance/index.tsx:107-108,630,640` — the instance table
reads `GET /api/instances`, not the write responses, and already renders
`resourceCountsAvailable === false` as `common.unavailable` and sorts those
rows after the numeric ones. Unchanged; this PR does not alter what the console
shows today, it stops the two write responses from contradicting the contract
the console relies on.
- No AI tool returns `InstanceVO` (`git grep -n resourceCountsAvailable --
server/src/main/java/org/apache/rocketmq/studio/ops/ai` is empty), so there is
no catalog or tool-output surface to update.
### How Did You Test This Change?
```
$ ./wb test --filter InstanceServiceTest
[ERROR] Tests run: 100, Failures: 1, Errors: 0, Skipped: 0
org.apache.rocketmq.studio.instance.InstanceServiceTest.updateInstanceShouldNotPresentUnmeasuredResourceCountsAsAvailableTest
org.opentest4j.AssertionFailedError:
Expecting value to be false but was true
at
org.apache.rocketmq.studio.instance.InstanceServiceTest.updateInstanceShouldNotPresentUnmeasuredResourceCountsAsAvailableTest(InstanceServiceTest.java:619)
$ ./wb test --filter
'InstanceServiceTest,InstanceControllerTest,InstanceResolverTest,MybatisPlusInstanceRepositoryTest'
[INFO] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0 -- in
…InstanceServiceTest
[INFO] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0 -- in
…InstanceControllerTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 -- in
…InstanceResolverTest
[INFO] Tests run: 20, Failures: 0, Errors: 0, Skipped: 0 -- in
…MybatisPlusInstanceRepositoryTest
[INFO] Tests run: 140, Failures: 0, Errors: 0, Skipped: 0
✓ 27.0s mvn -B -ntp test -DforkCount=1
-Dsurefire.failIfNoSpecifiedTests=false
-Dtest=InstanceServiceTest,InstanceControllerTest,InstanceResolverTest,MybatisPlusInstanceRepositoryTest
```
The new tests fail without the fix:
```
# only the default reverted to `true` in InstanceVO, both tests kept
$ ./wb test --filter InstanceServiceTest
[ERROR] Tests run: 101, Failures: 2, Errors: 0, Skipped: 0
updateInstanceShouldNotPresentUnmeasuredResourceCountsAsAvailableTest
Expecting value to be false but was true (InstanceServiceTest.java:619)
createInstanceShouldNotPresentUnmeasuredResourceCountsAsAvailableTest
Expecting value to be false but was true (InstanceServiceTest.java:641)
```
The assertions go red because both ask `isResourceCountsAvailable()` to be
`false` on a response nothing measured; with the default back at `true`,
exactly those two of the 101 tests in the class fail on `Expecting value to be
false but was true`, and the other 99 stay green — including the existing
`updateInstanceShouldMergeFieldsOntoExisting`, which pins the field-merge
semantics but not this flag. That is what shows the assertions pin the sentinel
rather than the builder.
### 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]
