tju-yxq opened a new issue, #5309:
URL: https://github.com/apache/rocketmq-dashboard/issues/5309
## Problem
The audit log is the only high-volume studio table with **no automatic
retention**. Expired sessions, metric snapshots, query history, AI
conversations and terminal notification-outbox rows all have scheduled cleanup
jobs (`@Scheduled` in `AuthService`, `CollectorScheduler`,
`QueryHistoryService`, `AiConversationService`, `NotificationOutboxService`) —
while the audit table grows forever unless an administrator remembers to open
the audit page and click the manual cleanup, and keeps remembering after every
incident.
On a busy multi-instance deployment the table grows without bound: every
mutating API call (topic, ACL, credential, settings, user management) writes a
row, so the operational tables that most need to stay small for query
performance are exactly the ones that never shrink. The manual cleanup exists
and is bounded, but "someone must remember" is not a retention policy — and the
audit page's own query/export performance degrades as the table grows, which
#1180 and #2269 already had to compensate for.
## Current behavior and reproduction
1. Deploy studio and operate it normally for months; every mutation writes
an audit row.
2. Look for any automatic cleanup: the audit page offers only a manual "清理"
modal; no scheduled job touches the table.
3. Forget to run it for a quarter and the table holds every row since day
one; the audit feed, summary and export all scan that ever-growing table.
The cleanup primitive already exists and is bounded —
`server/src/main/java/org/apache/rocketmq/studio/ops/audit/AuditService.java`
(around line 143):
```java
public int cleanupLogs(int beforeDays) {
...
LocalDateTime cutoff = LocalDateTime.now().minusDays(beforeDays);
return auditRepository.deleteBefore(cutoff, CLEANUP_BATCH_SIZE,
CLEANUP_MAX_BATCHES);
}
```
with `CLEANUP_BATCH_SIZE = 500` / `CLEANUP_MAX_BATCHES = 20` — but the only
caller is the manual `POST /api/audit-logs/cleanup` endpoint. The
scheduled-jobs inventory confirms the gap: every other growing table has a
`@Scheduled` cleanup; the audit table has none.
## Proposed behavior
- A `studio.audit.retention-days` property (env
`STUDIO_AUDIT_RETENTION_DAYS`) driving an hourly `@Scheduled` sweep that calls
the same bounded `cleanupLogs`.
- **Default 0 — keep forever.** This is deliberately different from the
diagnostic tables that default to 90 days: audit rows are compliance evidence,
and an upgrade must never start silently deleting them. Retention is opt-in per
deployment.
- Values above the 365-day maximum the manual endpoint enforces are clamped
to it with a warning (a misconfigured decade should not make the sweep fail
every hour).
- Repository failures are logged and swallowed — retention is hygiene, not
an application error.
- The manual cleanup endpoint and the audit page are unchanged.
- Follows the established pattern of `studio.query-history.retention-days` /
`studio.ai.conversation.retention-days` so operators configure it the same way.
## Acceptance criteria
- [ ] With retention unset (or 0), the scheduled sweep performs no
repository access at all.
- [ ] With retention 90, the sweep calls the bounded delete with a cutoff
~90 days in the past and the same 500×20 batch bounds as the manual endpoint.
- [ ] Retention above 365 is clamped to 365 with a warning instead of
throwing.
- [ ] A repository failure during the sweep is logged and does not propagate.
- [ ] The manual cleanup endpoint's validation (1..365) and behavior are
unchanged.
- [ ] `application.yml` documents the property with the keep-forever default.
## Importance
Must-have for long-running deployments. The current workaround is a
recurring human task (open the page, run the cleanup) — reliable to forget, and
unbounded table growth silently degrades every audit query, summary and export.
Every comparable table in the server already has this control; the audit table
is the omission.
## Duplicate check
Searched open and closed issues and PRs for `audit retention` and `audit
cleanup`. The adjacent closed items are #441 (validating the manual cleanup's
parameters), #2683 (bounding the delete batches the sweep reuses), #1570
(deduplicating destructive manual submissions) and #1180/#2269 (query
performance). None adds a scheduled retention; no open issue or PR covers it.
--
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]
