Hanabi9248 opened a new issue, #4860:
URL: https://github.com/apache/rocketmq-dashboard/issues/4860

   ### 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, commit 4c697f07acde460e2344375cb1f82669f5b270fd. Reproduced 
in the frontend hook test harness.
   
   ### Runtime Environment
   
   Windows, Node.js v24.19.0, npm 11.17.0, Vitest 4.1.10 with jsdom. This 
report is based on a deterministic hook regression test, not a deployed 
browser/cluster test.
   
   ### Connected RocketMQ Cluster
   
   Not required for reproduction: stream transport is mocked using the existing 
useAgentRun test harness; the hook under test is the real implementation.
   
   ### Build Toolchain
   
   _No response_
   
   ### Describe the Bug
   
   finishStream clears chatInFlightRef before checking whether requestId still 
owns the current stream. After switching conversations, an aborted old stream 
can settle after a new stream starts and release the new stream’s guard. A 
subsequent send is then admitted while the new stream remains active, 
superseding its request ID.
   
   ### Steps to Reproduce
   
   Using the existing useAgentRun.test.ts stream stubs:
   1. Start send(7, ...).
   2. Rerender the hook with conversationId 8; this aborts the first stream.
   3. Start send(8, ...) before the first transport promise settles.
   4. Reject the first transport promise with AbortError and await its cleanup.
   5. Call send(8, ...) again while the second stream remains pending.
   
   ### What Did You Expect to See?
   
   Only two transport calls in total. Cleanup for conversation 7 must not 
release the in-flight guard owned by conversation 8.
   
   ### What Did You See Instead?
   
   Three transport calls. The new regression fails with “expected ... to have a 
length of 2 but got 3”; the existing 14 hook tests pass.
   
   ### Additional Context
   
   The affected assignment is in web/src/pages/ai/hooks/useAgentRun.ts, 
finishStream. Moving the stale-request guard before chatInFlightRef.current = 
false should keep cleanup scoped to its owner. Checked #4740 and #4855: they 
modify the same hook but do not change this cleanup ordering.
   
   ### 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]

Reply via email to