Aias00 opened a new issue, #6953: URL: https://github.com/apache/rocketmq-dashboard/issues/6953
## Current behavior On `rocketmq-studio@c34535db0`, `AiConversationService.delete` stops an active run, then removes its event/run/conversation rows and workspace. `AgentRunHandle.stop` waits for the subprocess tree and cancels the worker, but cancellation is not worker-finalizer completion. `AiRunExecutor.finalizeRun` may still flush events and update rows after deletion. The service javadoc explicitly accepts a possible orphan `run_status` row. This is an enhancement of that documented lifecycle limit, not a claim that Stop never waits for a process. The observed path is `delete` -> `registry.stop` -> `handle.stop/awaitStop` -> `Future.cancel(true)`, while terminal persistence occurs separately in the executor. ## Proposed design for discussion Define an authoritative deletion transition that blocks new run admission, stop the existing run, await actual worker/sink finalization with a bounded timeout, and only then cascade rows and workspace. If draining fails or times out, preserve the rows/workspace and report a retryable outcome. `Future.isDone/get` after cancellation must not stand in for actual finalizer completion. Cover cancellation before the worker starts as well as active workers and concurrent admission. Open questions: whether to persist a deletion marker or use the existing single-instance conversation gate; timeout and retry semantics; crash recovery; whether orphan rows remain an intentionally accepted tradeoff. The runtime is documented as single-instance, so this proposal does not claim distributed lease support. ## Acceptance evidence for a future implementation Latch-controlled tests should prove no event can be written after the final cascade, no run can enter after deletion begins, cancellation-before-start cannot hang the drain, and a failed/timed-out drain preserves recoverable data. Include partial DB failure and repeated delete cases. No open PR specifically providing a manual-delete finalizer barrier was found. #5810/#4852 cover scheduled retention behavior, which is separate. -- 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]
