pilichoumao opened a new issue, #6608:
URL: https://github.com/apache/rocketmq-dashboard/issues/6608
### Before Creating the Bug Report
- [x] Searched existing issues and PRs; this is an input-side follow-up to
#1431, not a replacement for its export fix.
- [x] This defect is in RocketMQ Studio.
- [x] Reproduced using current rocketmq-studio sources.
### Studio Version
rocketmq-studio at 779b8c0e7aed2396d3cc72743dcd544ea48e9ae6; source-level
reproduction.
### Runtime Environment
Ubuntu 24.04 ECS, isolated Java 21 runtime; Jackson 3.1.4 and Hibernate
Validator 9.1. No database or live broker was needed for the reproduction.
### Connected RocketMQ Cluster
Not applicable: failure occurs at request validation, before broker access.
### Describe the Bug
Alert rule inputs accept non-finite thresholds. Jackson decodes the valid
JSON number 1e309 as positive infinity, and -1e309 as negative infinity.
AlertRuleRequestDTO validation accepts both. NativeAlertRulePolicy.validate
also accepts these values and NaN supplied by a Java caller, including legacy
Prometheus rules. The policy is shared by create, update and native trial
evaluation.
### Steps to Reproduce
1. Deserialize {"name":"High lag","threshold":1e309} into the actual
AlertRuleRequestDTO with Jackson 3.1.4.
2. Validate with Hibernate Validator: no violations; the converted rule
threshold is infinite.
3. Call NativeAlertRulePolicy.validate on a legacy metric rule with a NaN
threshold: no exception.
4. Repeat with -1e309. Compare with legitimate 0, -0.0, negative values,
1e308 and Double.MAX_VALUE.
### What Did You Expect to See?
Reject non-finite thresholds before persistence or evaluation, consistently
across HTTP and direct service inputs. Import validation should reject the
whole batch before writing any candidates. Explicit JSON null should not
silently become zero when a browser serializes an invalid number; omitted
thresholds should retain existing default-zero compatibility.
### What Did You See Instead?
Actual DTO and shared policy each accepted all three invalid controls. The
isolated finite-value prototype rejected them while preserving six legitimate
controls, including UNAVAILABLE with threshold zero. This establishes an
input-validation gap; it does not claim Infinity was persisted successfully to
MySQL.
### Additional Context
#1432 was consolidated into merged #1420 for #1431: that work protects
PromQL exports by substituting a finite fallback. Keep that safeguard for
legacy stored data. This follow-up concerns input rejection, not duplicate
export changes. Large finite export formatting (#6447) and signed-zero
comparison (#6445/#6486) are separate work.
Proposed scope: DTO finite-value validation and explicit-null rejection,
shared policy validation before legacy-metric early return, upfront import
candidate validation, and regression tests for invalid values, write boundaries
and legitimate finite values. No dependency or API additions.
--
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]
