zmuxuny opened a new issue, #7146: URL: https://github.com/apache/rocketmq-dashboard/issues/7146
### 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. Four deterministic AiRunServiceTest regressions fail with unchanged production code. ### Runtime Environment Linux, JDK 21.0.12.1, Maven 3.9.12. Real service/projector/session and recording SSE emitter with repository fixtures; no live MySQL, LLM, or RocketMQ needed. ### Connected RocketMQ Cluster Not applicable: run-scoped SSE replay within one owned AI conversation. ### Build Toolchain _No response_ ### Describe the Bug GET /api/ai/runs/{runId}/stream queries events by conversationId and afterSeq, then projects every row with the requested runId. It never checks each event row's runId. Earlier and later turns therefore enter the requested run's replay. An earlier COMPLETED run_status also sets terminalReplayed and suppresses the correct synthetic FAILED terminal for a requested run reaped after restart. The earlier terminal is relabeled with the requested runId and duration. ### Steps to Reproduce Create a conversation fixture with two runs: run A has text and COMPLETED; run B has unfinished text and was reaped as FAILED/SERVER_RESTART, with no stored terminal event. Attach to B with after=0. The stream contains A's answer and a COMPLETED terminal labeled as B instead of B's FAILED terminal. Additional deterministic cases cover a requested middle run with earlier/later turns, an active run that must keep tailing without an earlier terminal, and 5000 prior-run rows that exhaust the replay budget before the requested answer. All four new tests fail against the unchanged base (4 failures, 0 errors). ### What Did You Expect to See? Replay only rows owned by the requested run, retaining the existing live-tail and deduplication handoff. Use the recorded positive startSeq as a lower bound so earlier runs cannot consume the replay budget. Preserve a caller's later cursor. Do not use endSeq as a hard upper bound: reaped runs can have written text beyond their stale admission endSeq. ### What Did You See Instead? Other turns' text and terminal statuses appear under the requested run. A reaped FAILED run can be presented as COMPLETED. Large earlier histories can consume all 25 replay pages and omit the requested answer entirely. ### Additional Context This is same-owner content/status corruption, not a cross-account disclosure claim. The API documents after=0 as replaying the whole requested run. The normal short-history UI usually supplies timeline.lastSeq. A source-level reachable UI edge is a conversation exceeding its initial 25x200 timeline walk: activeRun is still returned and auto-attach can start with a cursor in an older turn. No browser reproduction of that large-history path is claimed. All-state issue/PR searches and nearby patches were checked: #5754/#6389 address paging, #5753 attach timing, #4999/#6469 duration, #7113 frontend continuation joining, and #7143 executor terminal publication order. None scopes projected rows to the requested run. ### 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]
