Aias00 opened a new issue, #7226: URL: https://github.com/apache/rocketmq-dashboard/issues/7226
### Before Creating the Bug Report - [x] Searched existing issues and PRs, including #4853/#4852, #4753/#4754 and merged #5810. Those protect live runs/remove workspaces; this is starvation of unrelated idle conversations behind a full busy page. - [x] This is a Studio defect on `rocketmq-studio`. ### Studio Version `rocketmq-studio`, commit `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, built from source. ### Runtime Environment macOS, JDK 21; reproducible with the H2 dev datasource. No browser or live broker required. ### Connected RocketMQ Cluster Not required; database retention only. ### Describe the Bug `deleteExpiredConversations` repeatedly calls `findIdsCreatedBefore(cutoff, batchSize)`, whose LIMIT is applied before checking active runs. If the oldest page consists entirely of conversations with QUEUED/RUNNING runs, every iteration reads that identical page and deletes nothing. Idle expired conversations after it are never visited during the pass, despite unused deletion capacity. ### Steps to Reproduce 1. Set retention-days=1, cleanup-batch-size=1 and cleanup-max-batches=2. 2. Persist two conversations created two days ago, with the busy conversation first in cleanup order. 3. Give the first conversation a RUNNING (or QUEUED) run with a fresh gmt_modified, so the orphan reaper correctly leaves it alone. Leave the second conversation idle. 4. Call `purgeExpired()` and inspect both conversations. ### What Did You Expect to See? Keep the busy conversation and its children; delete the idle expired conversation and its children within the bounded pass. ### What Did You See Instead? Both survive. The same busy ID consumes both iterations. With default settings the same situation occurs when the oldest 500 expired conversations are all active. ### Additional Context Select idle retention candidates before SQL LIMIT, retaining the existing service-level active-run recheck. This avoids spending every batch on the same known-busy prefix and preserves the rule that retention never stops live work. ### Are You Willing to Submit a Pull Request? - [x] Yes -- 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]
