pilichoumao opened a new issue, #6534: URL: https://github.com/apache/rocketmq-dashboard/issues/6534
### Before Creating the Bug Report - [x] Searched open/closed issues and pull requests, including #4876. - [x] Reproduced on current `rocketmq-studio` commit `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6`. ### Studio Version `rocketmq-studio`, `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6`. ### Runtime Environment Linux amd64 on ECS; Go 1.27.1. This is the rmqctl MCP client, so MySQL and browser are not involved. The tests run the real Session and SDK transport against a controlled HTTP boundary; they do not require a broker. ### Describe the Bug `MCPClientSession.SendMessage` applies the request timeout to the call context, but `sendWithReconnect` acquires `sendMu.RLock()` and `reinitialize` acquires `sendMu.Lock()` without observing that context. A caller can remain blocked after its deadline or cancellation until an unrelated request releases the lock. There are two paths: 1. A terminated session is reinitializing and holds the write lock while its initialize HTTP request is pending. A subsequent call cannot acquire the read lock and cannot return when its own context expires. 2. A long legitimate call holds a read lock. Another call receives a session-termination 404 and waits for the write lock to reconnect; its context can expire without ending that wait. ### Steps to Reproduce Initialize a session, hold the relevant HTTP request open with a channel, then start a second call with a 30ms deadline. Keep the unrelated HTTP request blocked and check that the cancelled call returns before releasing it. On the baseline both calls remain blocked beyond 200ms. Both scenarios failed in three consecutive runs on Linux; normal calls still complete when released. ### Expected Behavior Cancellation and the configured per-message timeout cover synchronization waits as well as HTTP work. A cancelled waiter must not send a call or replay a handshake later. Ordinary calls may remain concurrent; reconnection must retain its exclusive initialization/initialized barrier and generation checks. ### Proposed Scope Replace only the session send/reconnect admission lock with an internal context-aware FIFO reader/writer gate. Waiters use channels rather than polling or a goroutine per lock wait; a queued reconnect prevents later calls from overtaking it. Cancellation removes a queued waiter or releases a concurrently granted permit. Closing the session wakes queued callers. Add Session-level regressions for both blocked paths plus gate tests for concurrent readers, reconnect ordering, cancelled waiters, cancellation/grant races and session close. No new dependency or public protocol/API change is intended. #4876 concerns the separate decision to reconnect after the SDK clears its session ID; it is adjacent, not this lock-wait defect. Preserve the existing reconnection-failure and generation-barrier coverage. I will prepare a draft implementation with RED/GREEN and race-test evidence for review; the admission design remains open to maintainer feedback before it lands. -- 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]
