zmuxuny opened a new issue, #7141: URL: https://github.com/apache/rocketmq-dashboard/issues/7141
### 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 `master` branch, or I have stated the exact version I am running below. ### Studio Version rocketmq-studio at 127c47b06a268cc74224d5f34c56ec7c36ac0d55; reproduced with repository unit-test seams against unchanged production code. ### Runtime Environment Linux, Eclipse Temurin JDK 21.0.12.1, Maven 3.9.12. Deterministic stub AgentProvider and recording SSE emitter; no live LLM, MySQL, or browser deployment required. ### Connected RocketMQ Cluster Not applicable: the failure is in hosted AI run finalization and does not call a RocketMQ cluster. ### Build Toolchain _No response_ ### Describe the Bug AiRunExecutor forwards a successful ResultMeta to AiEventSink immediately. AgentEventProjector persists run_status and sends live run_finished(COMPLETED) at that point, while rmq_ai_run is still RUNNING. Only after the provider returns does finalizeRun update the run row. This contradicts the executor's documented row-before-wire order. If that terminal update throws, an attached observer has already received success even though the stored run remains RUNNING. ### Steps to Reproduce In AiRunExecutorTest, script TextDelta followed by ResultMeta with subtype success. Inspect the real recording emitter inside runRepository.update when status becomes COMPLETED, before saving the row copy. The observer already contains one run_finished. In a second case, throw from that terminal update and retain the prior RUNNING row; the observer still contains one run_finished. The two focused JUnit regressions both fail against unchanged production code (2 failures, 0 errors): expected terminal-frame count 0, observed 1. ### What Did You Expect to See? Record provider success as an outcome, then emit exactly one live terminal after the final run-row update and cache finalization. Keep success-before-stop precedence and the terminal timeline sequence so reconnect replay can deduplicate the delayed live frame. Use the recorded run duration even when the provider result omits duration. ### What Did You See Instead? Live COMPLETED precedes the terminal row write; a failed row write does not retract the already-sent success. A provider result without duration also sends a terminal frame without the duration that finalization subsequently records. ### Additional Context Scope: live terminal publication consistency. The current Studio page waits for event:done/stream completion before its final refetch, so this report does not claim a same-page immediate-send 409. It also does not claim to make the timeline INSERT and run-row UPDATE transactional for attach replay. Related work reviewed: #6385 preserves success-before-stop precedence; #7031 reports incomplete timeline persistence; #7044 bounds whole-run execution; #4999/#6469 concern replay duration. These do not defer live successful-result publication until the terminal run-row update. ### 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]
