Frun1na opened a new issue, #4853: URL: https://github.com/apache/rocketmq-dashboard/issues/4853
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and found no similar issue. ### What Happened The scheduled AI conversation retention sweep and the manual delete took two different paths through the same lifecycle event. `AiConversationService.delete` stops the conversation's active run through the registry and removes the agent workspace; `deleteCascade` (the retention sweep's cascade) did neither — it deleted the event / run / conversation rows directly. Two consequences: 1. **Workspace leak.** Every purged conversation whose agent ever ran leaves a `conv-<id>/` directory (rmqctl config, system prompt, `home/` with the CLI's resume state) under the configured workspace dir — a volume `RmqctlWorkspace` documents as persistent — with no reclaim path. The leak accumulates across restarts, one directory per purged conversation. 2. **Purging under a live run.** A conversation created past the retention cutoff but still streaming gets its rows deleted mid-run: the worker keeps appending orphan event rows, the finalize update is a no-op against the missing row, and the subprocess keeps writing into a workspace that now belongs to nothing. ### Expected Behavior The retention sweep should mirror `delete`: stop any run the registry still owns before deleting the rows, and remove each conversation's workspace afterwards — the same lifecycle contract, whichever path ends the conversation's life. -- 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]
