zmuxuny opened a new issue, #5490: URL: https://github.com/apache/rocketmq-dashboard/issues/5490
### 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 Repository: apache/rocketmq-dashboard Branch: rocketmq-studio Commit: 6a68042fa73a513f40436ca721944b4de48181ec Component: rmqctl, tested from source. ### Runtime Environment Linux, Go 1.27.1. Deterministic Go regression tests using the real mcp-go Streamable HTTP transport and the existing in-memory roundTripFunc HTTP test harness. No browser or MySQL dependency. ### Connected RocketMQ Cluster No live RocketMQ cluster is required for this client lifecycle reproduction. The test endpoint simulates an expired MCP session and one transient initialized-notification HTTP 502. ### Build Toolchain _No response_ ### Describe the Bug After a session expires, rmqctl replays initialize followed by notifications/initialized. If the initialize response succeeds but the notification fails, the next caller does not repair that incomplete handshake before sending an ordinary request. applyInitialization increments state.generation before the notification succeeds. reinitialize leaves that generation committed on failure, while sendWithReconnect does not gate later requests on handshake completion. A queued caller can also see the changed generation and incorrectly treat the failed reconnect as complete. ### Steps to Reproduce Use the existing roundTripFunc harness with the real mcp-go Streamable HTTP transport: 1. Complete the original initialize/initialized exchange. 2. Return HTTP 404 to the next tools/list request, simulating an expired session. 3. Accept the replayed initialize, but return one HTTP 502 for notifications/initialized. 4. Retry tools/list after that transient failure. The sequential retry and queued-caller regressions each reproduced the failure 5/5 times under go test -race, with no race-detector warnings. ### What Did You Expect to See? Treat reinitialization as complete only after both protocol steps succeed. Later and queued callers must complete or fail the handshake before forwarding ordinary requests. A transient handshake failure should remain recoverable on a later call, without an unbounded retry loop or replay of a tool call already accepted by the server. ### What Did You See Instead? The original request correctly reports the notification failure. The retry sends tools/list directly to the half-initialized replacement session without another initialized notification. A test endpoint enforcing readiness returns JSON-RPC -32600, Session not initialized. Observed counters: initialize=2, initialized=2, unready-tool-calls=1. This demonstrates missing recovery independently of how a production endpoint rejects a premature request. No production incident or message loss is claimed. ### Additional Context MCP lifecycle: https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle#initialization Duplicate check: searched issues and PRs for reinitialize, reconnect, initialized notification, and session handshake. #4880 / #4876 concerns a different 404 race; this report concerns a reconnect that has started but whose initialized notification fails. The untouched rmqctl baseline passes make -C rmqctl ci, including the full race suite, go vet, catalog consistency, six OS/architecture builds and per-target license checks. A focused regression-tested fix can be prepared. AI assistance was used for investigation. ### Are You Willing to Submit a Pull Request? - [ ] 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]
