unbridled-41 opened a new issue, #5894:
URL: https://github.com/apache/rocketmq-dashboard/issues/5894

   ### Studio Version
   branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is 
based on it)
   deployed as: not required to reproduce
   
   ### Runtime Environment
   
   Reproduced with the frontend tests (`cd web && npx vitest run 
src/pages/ops/__tests__/AuditPage.test.tsx`); the browser locale does not 
matter.
   
   ### Connected RocketMQ Cluster
   
   Not involved. The rows live in Studio's own `rmq_operation_audit` table.
   
   ### Describe the Bug
   
   `GET /audit-logs/export` refuses any filtered result set above 10000 rows 
with an actionable message:
   
   ```java
   // server/.../ops/audit/AuditService.java:82-84
   if (page.getTotal() > MAX_EXPORT_RECORDS) {
       throw new BusinessException(400,
           "Audit log export exceeds the maximum of " + MAX_EXPORT_RECORDS + " 
records; narrow the filters");
   }
   ```
   
   The audit page drops it and answers with generic retry advice instead:
   
   ```ts
   // web/src/pages/ops/audit.tsx (before)
   } catch {
     message.error('导出审计日志失败,请稍后重试');
   }
   ```
   
   Retrying can never work - the same filters produce the same 400 - and the 
only actionable fact ("narrow the filters") is exactly what the toast omits. 
Every write in the product is audited (topic, group, ACL, settings, cloud 
instance), so a deployment reaches 10000 matching rows routinely, after which 
the page's Export button is permanently unusable with a misleading message.
   
   ### Steps to Reproduce
   
   1. Accumulate more than 10000 audit rows matching the current filter (or 
point the page at a seeded table).
   2. Studio → Audit → Export.
   3. The toast reads "导出审计日志失败,请稍后重试" although the response body names the cap 
and the remedy.
   
   ### What Did You Expect to See?
   
   The server's message, the way the alert page surfaces a rule-import conflict 
(`AlertsPage.test.tsx` pins that shape) and the instance page surfaces its 
failures.
   
   ### What Did You See Instead?
   
   A generic retry message, with the response's `message` discarded.
   
   ### Evidence
   
   - `web/src/pages/ops/audit.tsx` (`handleExport`'s catch), 
`server/src/main/java/org/apache/rocketmq/studio/ops/audit/AuditService.java:82-84`.
   - `web/src/utils/apiError.ts` (`describeApiError`) already exists and is 
used by `pages/ops/alerts.tsx` and `pages/instance/index.tsx` for the same 
purpose; `exportAuditLogs` is a JSON call, so `error.response.data.message` 
carries the reason.
   - `cd web && npx vitest run src/pages/ops/__tests__/AuditPage.test.tsx` - 
before the fix the new case fails with `Unable to find an element with the 
text: /narrow the filters/`.
   
   ### Impact
   
   Operators cannot export the audit log on any deployment whose audit table is 
large, and the message actively misleads them into retrying; the failure reason 
never reaches the user.
   
   ### Acceptance Criteria
   
   - The export failure shows the server-supplied reason when there is one and 
keeps the existing message otherwise, with a regression test.
   
   **Corresponding PR:** #5894


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