Frun1na opened a new issue, #4697: URL: https://github.com/apache/rocketmq-dashboard/issues/4697
### 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 branch: rocketmq-studio git commit id: 7ce9a68215c4cd1c7025013d02135b43b6aa6ba1 deployed as: built from source (`cd server && mvn -B -ntp package -DskipTests`) ### Runtime Environment OS: Windows 11 with WSL2 (Ubuntu 24.04.3 LTS) MySQL: 8.0.36, container from `deploy/docker-compose.yml` browser: Chrome 141 ### Connected RocketMQ Cluster Not involved: the defect is in the AI page's client-side run handling, verified with Vitest and a mocked timeline endpoint. ### Build Toolchain Node.js 20.19.0, npm 10.8.2 ### Describe the Bug Generation belongs to the run, not to the HTTP connection, so the timeline reports the run still streaming as `activeRun` and the AI page re-attaches to it. `useConversationTimeline` kept that run without recording which conversation it came from — and replacing it requires a refetch, which is asynchronous. So after the user switches away from a generating conversation, `activeRun` is still the previous conversation's run for at least one commit. `useActiveRunAttach`'s effect re-runs in exactly that commit: `useAgentRun`'s abort-on-conversation-change re-renders, and the effect that clears the one-attempt marker runs first in the same commit. The effect then calls `attach(conversationId, previousRunId, lastSeq)` with the new conversation id. Two things let it through rather than catching it. `startStream` refuses a stream whose frames belong to another conversation, but it compares against `conversationIdRef`, which the earlier effect in the same commit has already updated to the new conversation. And the attach endpoint (`POST /api/ai/runs/{runId}/stream`) is addressed by run id alone, so there is nothing server-side to reject it either. The result is that the previous conversation's run is attached to the conversation on screen: its live frames are folded into the wrong transcript, and the stop button acts on that run while the user believes they are looking at a different conversation. ### Steps to Reproduce 1. Open a conversation that is currently generating (send a message and leave it running). 2. Switch to another conversation from the list. 3. Observe the new conversation's transcript: the previous run's frames are appended to it. ### What Did You Expect to See? The new conversation attaches only its own active run, if it has one. While that conversation's timeline has not loaded yet, the page has no active run to attach, and it should not attach anything. ### What Did You See Instead? The previous conversation's run is attached to the new one and its frames render under the wrong transcript. ### Additional Context I have a fix ready: PR #4696. ### 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]
