Frun1na opened a new issue, #6519: URL: https://github.com/apache/rocketmq-dashboard/issues/6519
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced by a unit test against that commit (the affected code is the backend service) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is the missing audit write in `LiteTopicService`; the audit table is `rmq_operation_audit` from `db/schema.sql` browser: not applicable — reproduced in a JUnit 5 service test ### Connected RocketMQ Cluster RocketMQ version: not applicable — the broker call is stubbed in the unit test; the defect is that the console records nothing about it access mode: not applicable deployment: not applicable ### Describe the Bug `LiteTopicService.extendTTL` (`server/src/main/java/org/apache/rocketmq/studio/instance/topic/LiteTopicService.java:62`) rewrites the broker-side `lite.topic.expiration` of a live parent topic after validating the request through `ResourceOwnershipGuard` (`:74-75`) and delegating to the provider (`:80`). It writes no operation-audit row: - The service has no `OperationAuditService` dependency at all, and `RocketMQLiteTopicProvider.extendTTL` — the Apache implementation that performs the broker write — records nothing either. - Every comparable operator-initiated change is audited: topic and consumer-group create/update/delete and offset resets (`MetadataService.executeWithAudit`, plus `RocketMQAdminClientImpl` on the Apache path), DLQ resends, ACL rules and users, cloud credentials, proxy addresses and reloads, certificates, cluster config and settings. The result is that extending the TTL of a LiteTopic — an operator action that changes how long messages stay readable — cannot be attributed in `/api/audit-logs` afterwards. ### Steps to Reproduce 1. As an administrator, `POST /api/liteTopic/extendTTL` with `{"instanceId":"instance-a","topicPattern":"chat","newTTL":600000}` on an instance that owns the `chat` parent topic. 2. `GET /api/audit-logs?operationType=UPDATE_LITE_TOPIC_TTL`: no such row exists (in fact no row at all is written for the request). 3. Without a running broker, the same path is exercised from a unit test: `LiteTopicServiceTest.extendTTLRecordsTheBrokerSideChangeTest` drives `service.extendTTL("instance-a", "chat", 600_000L)` over a mocked `LiteTopicProvider` and a mocked `OperationAuditService`. ### What Did You Expect to See? One audit row per attempt that reached the provider: operation `UPDATE_LITE_TOPIC_TTL`, resource type `TOPIC`, the parent topic as the resource, the cluster the ownership row belongs to, and a detail carrying the instance and the requested TTL in milliseconds — `SUCCESS` after a completed write, `FAILED` with the provider's message when the broker write fails (the same two outcomes `MetadataService.executeWithAudit` records). A request rejected before the provider call (blank pattern, non-positive TTL, ownership conflict) records nothing. ### What Did You See Instead? `OperationAuditService` was never called: the assertion `verify(auditService).record("UPDATE_LITE_TOPIC_TTL", "TOPIC", "chat", "cluster-a", "instance=instance-a, newTTLMillis=600000", "SUCCESS", null)` fails with "Wanted but not invoked … Actually, there were zero interactions with this mock." ### Additional Context A fix with a regression test follows in a pull request. ### 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]
