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

   ### Before Creating the Bug Report
   
   - [x] I searched open/closed issues and PRs and found no existing fix for 
this failure mode.
   - [x] The affected behavior is present on current `master` 
(`987b748e8f4f421c5cd3c4c4e51a064cc7e59f18`).
   
   ### Problem
   
   Studio's Aliyun provider checks the decoded `data` field for several read 
APIs but never checks the SDK response body's business `success` flag. The 
pinned `alibabacloud-rocketmq20220801:5.0.8` response bodies for `ListTopics`, 
`ListConsumerGroups`, `ListTopicSubscriptions`, 
`ListConsumerGroupSubscriptions`, `GetConsumerGroupLag`, `ListMessages`, and 
`GetTrace` all expose `success`, `code`, and `message`.
   
   When one of these calls completes normally with `success=false`, the current 
provider typically sees a null/empty `data` value and converts the provider 
failure into valid-looking empty operational data.
   
   ### Impact
   
   Provider permission, throttling, account, or other business failures can be 
displayed as:
   - no Topics or Consumer Groups;
   - no subscriptions;
   - no consumer progress/lag;
   - no matching messages;
   - no trace nodes.
   
   This is dangerous during incident response because an operator is told that 
the resource/data is absent rather than that the cloud query failed.
   
   ### Expected behavior
   
   For these Aliyun read paths, a decoded response body with `success != true` 
must fail closed with a 502-style `BusinessException`, retaining provider 
`message`/`code` when available. Successful empty results (`success=true` with 
an empty data collection) must remain valid empty results. Existing SDK 
exceptional-completion mapping stays unchanged.
   
   ### Verification plan
   
   Add deterministic provider regressions that return normally completed SDK 
futures with `success=false` and prove the unmodified provider returns empty 
results instead of an error. Then make the same cases fail closed and retain 
existing successful-empty/read mapping tests.
   
   This is separate from #4498/#4499, which cover mutating OpenAPI responses 
only.
   
   AI-assisted source audit; response signatures were checked against the 
pinned 5.0.8 SDK jar.
   


-- 
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