Frun1na opened a new issue, #6105: URL: https://github.com/apache/rocketmq-dashboard/issues/6105
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `5e4c39b0` deployed as: reproduced by a unit test against that commit (`ConsumerGroupReadToolHandlersTest`) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the MCP/AI tool output contract, no database involved browser (for UI issues): not applicable — the console side is tracked separately (see below) ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed `MetadataService` in a unit test access mode: not applicable deployment: the live case is a group whose consume stats carry no consumed-message timestamp (e.g. POP-only), and every Tencent/Aliyun instance, whose provider never sets the delay ### Describe the Bug `rmq.group.detail` publishes `delaySeconds` at its zero default when the provider could not measure a delay, so a model reading the tool output is told the group is caught up: - `ConsumerGroupVO` marks the case: `RocketMQMetadataProvider.java:420-434` keeps `delaySeconds = 0` with `timestampAvailable = false` when there is no newest consumed-message timestamp (`RocketMQAdminClientImpl.java:207-210` does the same), and `ConsumerGroupVO.java:46-48` carries the flag as `consumptionTimestampAvailable` ("Whether broker consume stats include a consumed-message timestamp for delay calculation"). The providers of Tencent and Aliyun never set either field, so for those instances the pair is the default `0` / `false`. - `GroupDetailOutput` dropped the flag and published the number: the record declared `int delaySeconds` (`contract/group/GroupDetailOutput.java:50`) and mapped `source.getDelaySeconds()` verbatim, so the tool output contained `"delaySeconds": 0` with no way to tell it apart from a measured zero. - The record's sibling signals already carry their unknown states: `onlineInstances` documents `-1`, `Progress.totalLag` becomes `-1` when any queue lag is unknown, `retryMaxTimes` is omitted when it cannot be stated, and the health ladder answers `UNKNOWN` for an unresolved lag (#5091). The delay was the one number without that treatment, which is the same "unknown collapsed into a measurement" class as #5449's `metricsAvailable` for lag/TPS. The console has the same root cause and is tracked separately: #5919 (fixed for the page by #5920). This issue covers the tool output contract, which #5920 does not touch; the schema the model reads (`server/src/main/resources/tool-catalog/tools/group.yaml`, `rmq.group.detail`) also listed `delaySeconds` as required and non-nullable, so the contract itself claimed a number is always available. ### Steps to Reproduce ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=ConsumerGroupReadToolHandlersTest ``` `detailOmitsTheDelayWhenNoConsumedMessageTimestampIsAvailableTest` stubs a group with `consumptionTimestampAvailable = false` and `delaySeconds = 0` (the pair the provider produces for a group without a consumed-message timestamp, and the default pair for every cloud group) and asserts the serialized tool output carries no `delaySeconds` at all. Before the fix the payload has `"delaySeconds": 0` and the assertion fails with `Expecting value to be false but was true`. ### What Did You Expect to See? An unmeasurable delay must not travel as a number: the field should be absent (or explicitly unknown), with the output schema saying so, the way the sibling unknown states of the same record are published. A delay that was actually measured must stay unchanged. ### What Did You See Instead? The tool output contained `"delaySeconds": 0`, which reads as "the group has just consumed / nothing is delayed" in the model's view, for a group the server itself marks as unmeasurable. ### Additional Context A fix with regression tests follows in a pull request. The console-side fix for the same root cause is #5920 (issue #5919) and is not duplicated here. -- 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]
