Hanabi9248 opened a new issue, #5061: URL: https://github.com/apache/rocketmq-dashboard/issues/5061
### 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 0228dad5b9c9460f3e18c5c3e2b56c6525856198. ### Runtime Environment Windows amd64, Go 1.27.1. Reproduced with the actual mcp-go v0.58.0 transport and a controlled HTTP RoundTripper in internal/studio tests. ### Connected RocketMQ Cluster Not required; the failure occurs in the CLI session lifecycle before a cluster operation. ### Build Toolchain _No response_ ### Describe the Bug After a 404 triggers reinitialization, initialize succeeds but notifications/initialized can fail (for example HTTP 503). reinitialize returns that error, but applyInitialization has already advanced the generation and the replacement session ID remains installed. The next SendMessage sends tools/list directly on that session without completing the failed initialized notification. ### Steps to Reproduce 1. Complete the initial initialize/initialized exchange. 2. Return HTTP 404 for a tools/list request, then succeed the replacement initialize with a new session ID. 3. Reject its notifications/initialized with HTTP 503 before delivery. The first caller receives this error. 4. Send tools/list again and record outgoing requests. It reaches the replacement session with no successful initialized notification. ### What Did You Expect to See? Keep normal requests behind the reconnect handshake. A later attempt should complete the pending initialized notification, or return its error without sending the normal request. Concurrent callers must not treat a partially completed handshake as ready. ### What Did You See Instead? A focused regression fails: initialized=2, initialized notifications attempted=2, normal requests sent before the replacement session is ready=1. The second caller can receive a successful response even though the reconnect handshake did not complete. ### Additional Context Related #4876/#4880 addresses a different condition: the transport clears the session ID before a concurrent sender takes its snapshot. This report starts after replacement initialize succeeds and concerns failure of the subsequent initialized notification. The probe calls the actual MCPClientSession.SendMessage path; it does not replace the production session implementation. A focused fix and regression coverage will follow. ### 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]
