pilichoumao opened a new issue, #7274: URL: https://github.com/apache/rocketmq-dashboard/issues/7274
### Before Creating the Bug Report - [x] I searched existing issues and PRs, including #7055 and #7124. - [x] This is a RocketMQ Studio defect. - [x] Reproduced against the current `rocketmq-studio` source. ### Studio Version `rocketmq-studio`, commit `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, built from source. ### Runtime Environment Linux ECS, JDK 21. The reproduction invokes the real MetricsService and RestClient against a loopback HTTP fixture. It does not require MySQL or a browser and is not a claim of a full deployed Studio/Prometheus integration test. ### Connected RocketMQ Cluster Not required: this is the Prometheus-compatible range-query transport, before any RocketMQ-specific metric evaluation. ### Describe the Bug `MetricsService.parseStepMillis` validates `step.strip()`, but `AbstractPrometheusCompatibleMetricsSource.query` puts the original `query.getStep()` into the HTTP form. A padded value accepted by the service is therefore rejected by Prometheus instead of behaving like its validated value. ### Steps to Reproduce 1. Configure a Prometheus-compatible data source. 2. Submit a range query with metric `up`, start `1000000`, end `1000300`, and step `" 30s "` or `" 30 "`, through the default metrics query or configured-data-source query. 3. Observe that window/sample validation accepts it but the outgoing decoded `step` form field still contains the surrounding spaces. 4. Compare unpadded `"30s"` and `"30"`, which are sent unchanged and accepted. ### What Did You Expect to See? Send the same normalized step that the service used to validate the window. Keep the caller DTO unchanged and retain the existing duration grammar, positive-step validation and sample limit. ### What Did You See Instead? Padded values pass local validation and cause an upstream bad-data response. The ECS HTTP reproduction has two passing unpadded controls and two failing padded cases. Applying `strip()` only to the outgoing step form field makes all four pass. ### Additional Context Prometheus's [`parseDuration`](https://github.com/prometheus/prometheus/blob/v3.5.0/web/api/v1/api.go#L2083) first uses `strconv.ParseFloat`, then [`model.ParseDuration`](https://github.com/prometheus/common/blob/v0.65.0/model/time.go#L205); neither trims the input. Running that upstream duration source with the same numeric parsing order independently confirmed that `30s`/`30` are accepted and their padded equivalents rejected. The HTTP fixture enforces these four cases; a live Prometheus process was not used. #7055 and #7124 address numeric syntax in `MetricsService` and its unit tests (issue #6948). Neither changes the shared HTTP transport. This report is narrowly about preserving consistency between the already accepted stripped value and the form payload; it does not expand numeric syntax or duplicate their parser changes. ### Are You Willing to Submit a Pull Request? - [x] Yes, with HTTP-level regression tests. -- 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]
