nawei123 opened a new issue, #6919:
URL: https://github.com/apache/rocketmq-dashboard/issues/6919

   ### Before Creating the Bug Report
   
   - [x] Searched open issues and PRs for duplicate fixes.
   - [x] This is a RocketMQ Studio frontend defect.
   - [x] The exact tested revision is stated below.
   
   ### Studio Version
   
   `rocketmq-studio`, commit `c34535db0819d02f68e50a856cb3d2614f0dc5dd`, source 
checkout.
   
   ### Runtime Environment
   
   macOS arm64, Node.js 24.19.0, Vitest 4.1.10 with jsdom. Reproduced in real 
alert-page component tests with the ordinary frontend API services mocked. No 
browser or deployed MySQL instance was used for this reproduction.
   
   ### Connected RocketMQ Cluster
   
   Not applicable to the reproduction: the defect occurs in frontend form 
initialization and is observable in the payload sent to the rules service, 
without a live cluster.
   
   ### Describe the Bug
   
   The alert-rule editor converts legacy native ratio thresholds to percentage 
points inside the successful response handler of `listNativeAlertMetrics`. 
Saving and testing already mark native ratio thresholds as `%` regardless of 
that request's status. Consequently, editing or duplicating a legacy rule with 
`metric=broker.disk.usage_ratio`, `threshold=0.29`, and `thresholdUnit=null` 
can submit `threshold=0.29, thresholdUnit=%` instead of `29, %` while discovery 
is pending, or after discovery fails.
   
   ### Steps to Reproduce
   
   1. Return an existing rule with `metric=broker.disk.usage_ratio`, 
`threshold=0.29`, and `thresholdUnit=null` from the rules service.
   2. Keep its `listNativeAlertMetrics` request pending, or reject the request.
   3. Open Edit (or Duplicate) and submit the unchanged rule.
   4. Observe the payload passed to the rule save service. Test Run has the 
same conversion problem.
   5. Separately, resolve discovery after editing the displayed threshold: the 
delayed conversion can overwrite the operator's input.
   
   ### What Did You Expect to See?
   
   The editor initializes the threshold as `29` and its unit as `%` together, 
before discovery completes. Save and Test Run preserve that value. Discovery 
populates metric choices without rewriting an already edited threshold. 
Already-percent and non-ratio rules retain their values.
   
   ### What Did You See Instead?
   
   The payload contains `threshold=0.29, thresholdUnit=%`, lowering the 
threshold by 100x. The save service is actually called; this is not a 
form-validation failure.
   
   ### Additional Context
   
   Restoring the original production source makes six new regression cases fail 
while three compatibility controls pass. With synchronous initialization, all 
46 alert-page tests pass. Coverage includes all three native ratio metrics, 
Edit, Duplicate, pending/failed/late discovery and Test Run.
   
   Related PR #6297 addresses stale test results after criteria changes; PR 
#5891 concerns unit labels in the rules table. Neither fixes initialization 
depending on discovery. AI assistance was used to investigate, implement, 
review and verify the change.
   
   ### 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]

Reply via email to