youngkermit8-coder opened a new issue, #6948: URL: https://github.com/apache/rocketmq-dashboard/issues/6948
### 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 `master` branch, or I have stated the exact version I am running below. ### Studio Version Source-built rocketmq-studio at a92c23144408cdf5729707050e9ecd9b75f1bad0. Checked on 2026-10-18: c34535db0819d02f68e50a856cb3d2614f0dc5dd has the same server/ tree. This is a service-level test and direct-source probe, not a deployed Studio HTTP application. ### Runtime Environment Windows; isolated Prometheus 3.5.0 on loopback with no scrape targets or remote writes. ### Connected RocketMQ Cluster None required: this reproduces a Prometheus range query using vector(1). ### Build Toolchain Temurin JDK 21.0.12, Maven 3.9.9. This is not a build failure report. ### Describe the Bug MetricsService rejects numeric step forms `.5`, `1.`, `+1`, `1e1`, `5E-1`, and `1e0` before dispatch, although Prometheus 3.5.0 and the actual Studio PrometheusMetricsSource accept them. The DTO documents step as a duration or number of seconds. The current service pattern requires digits on both sides of a decimal point and excludes scientific notation. Both default and configured-source query paths are affected. ### Steps to Reproduce 1. At the stated baseline, instantiate the real MetricsService with a recording MetricsSource. Set a MetricQueryDTO to metric=vector(1), start=1700000000, end=1700000020, step=1e1. 2. Call service.query(query). It raises PrometheusException with status 400 and "Metric query step is invalid" before calling the source. This is a service-level status, not a captured controller response. 3. Send this request to isolated Prometheus 3.5.0: GET /api/v1/query_range?query=vector%281%29&start=1700000000&end=1700000020&step=1e1 It returns HTTP 200 with 3 samples. Calling the actual Studio PrometheusMetricsSource directly returns the same samples. 4. For the same range, .5, 1., +1, 5E-1, and 1e0 return 41, 21, 21, 41, and 21 samples respectively through the source but are rejected by the service. Existing forms 0.5, 1h30m, and 30s work as controls. ### What Did You Expect to See? Accept positive decimal/exponent numeric seconds without rewriting the dispatched step. Preserve duration validation, the 31-day range limit, and the 11,000-point budget. For the 20-second reproduction range, 0.001, .001, and 1e-3 should all remain rejected because they exceed the point budget. ### What Did You See Instead? Equivalent numeric forms are rejected as invalid syntax before reaching a backend that accepts them. ### Additional Context A local prototype includes regression coverage for both query entrypoints, semantic profile resolution, sample-budget boundaries, and extreme exponents. It was verified on a fresh c34535d snapshot: the Linux backend suite passed 3,793 tests with no failures, errors, or skips, and packaging passed. These results apply to the prototype; it is not yet published or merged. Before proposing the patch, I would like feedback on the intended grammar: should Studio accept decimal/exponent numeric seconds while leaving hexadecimal float syntax such as 0x1p0 unsupported? The prototype does not attempt bit-for-bit emulation of Go floating-point rounding or alter duration quantization. Issue/PR keyword searches on 2026-10-18 did not identify an equivalent change. Related #2175 concerns duration ordering; #5009 concerns the metrics catalog input contract. These searches are finite, not proof that no duplicate exists. AI assisted the investigation, prototype, and test preparation. A tested local prototype is available; I can prepare a focused PR after agreement on the supported grammar. References: https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries https://github.com/prometheus/prometheus/blob/v3.5.0/web/api/v1/api.go ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
