pilichoumao opened a new issue, #6324: URL: https://github.com/apache/rocketmq-dashboard/issues/6324
### Before Creating the Bug Report - [x] Searched issues and PRs for stdio concurrency, callSlots and progress. #6317 fixes output failures/cleanup, #4649 SIGTERM, and #5491 reconnection; this is a distinct scheduling boundary. - [x] Defect in Studio rmqctl. - [x] Reproduced on current rocketmq-studio. ### Studio Version rocketmq-studio 5e4c39b053c35a5598cc79ff331b8a54e649d7b1, built from source. ### Runtime Environment macOS / Go, real MCP initialization and POST SSE against an in-process HTTP endpoint; no broker/database. ### Connected RocketMQ Cluster Not required: the defect is in the stdio select loop. ### Describe the Bug After initialization, 64 outstanding calls occupy all call slots. The next stdin event enters handleEvent and blocks acquiring a slot, preventing the main select loop from forwarding server progress notifications while those calls remain pending. Completion eventually frees a slot; this is not a claim of permanent deadlock. ### Steps to Reproduce Complete initialize/initialized, submit more than 64 tools/list requests, hold the first 64 HTTP responses open, then send notifications/progress on one actual POST SSE response. Observe stdout before releasing the held responses. ### What Did You Expect to See? Keep processing notifications/results/cancellation at the concurrency limit; defer reading additional input until capacity is available. Keep concurrency at 64 and eventually process queued requests. ### What Did You See Instead? The received progress notification is delayed behind the queued stdin request until a call completes. This was reproduced repeatedly against the actual HTTP/SSE transport. ### Additional Context Scope: gate stdin event consumption at maxConcurrentCalls. Do not increase buffers/concurrency, change handshake/reconnect rules or replay requests. Test actual HTTP peak concurrency, queued input completion, clean EOF and cancellation. Verify compatibility with #6317 without including its changes in this PR. ### Are You Willing to Submit a Pull Request? - [x] Yes. -- 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]
