zmuxuny opened a new issue, #6299: URL: https://github.com/apache/rocketmq-dashboard/issues/6299
### 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 Originally traced on `rocketmq-studio@0228dad5`. The October 4 revision of #5255 was validated against `rocketmq-studio@6a68042fa73a513f40436ca721944b4de48181ec`; the latest published review revision is `fa3641209c4bffccc515533ecddf61c75548d2b5`, validated on October 10. The results below are the dated results already published in #5255, not fresh October 12 test runs. ### Runtime Environment Java 21, Apache RocketMQ proxy-connected consumer diagnostics through `ProxyConsumerResolver`. Controlled regressions use mocked remoting clients, so no live broker or cloud account is required. October 10 focused validation used Temurin 21, Maven 3.9.11, one test fork with 384 MiB heaps, and the Mockito startup agent. ### Connected RocketMQ Cluster Apache RocketMQ through Proxy remoting. Controlled regressions use mocked clients; no live cluster is required. ### Build Toolchain Java 21 / Maven 3.9.11. Exact dated validation and limits below. ### Describe the Bug This continues #5057 → #5555. The [stale-bot comment](https://github.com/apache/rocketmq-dashboard/issues/5555#issuecomment-6115548623) was posted on 2026-10-12 at 00:22:10 UTC, and github-actions[bot] closed #5555 at 00:22:12 UTC after seven days without issue activity. The timeline contains no maintainer rejection or fix commit. The existing implementation is **#5255**, still open and Ready for review at head `fa3641209c4bffccc515533ecddf61c75548d2b5`. No new implementation PR is needed. This issue preserves the defect and its active review trail; it does not claim a new design approval or an upstream merge. In the reported implementation, `ProxyConsumerResolver.remotingClient()` sets `clientStarted=true` before `NettyRemotingClient.start()` completes. If startup throws, the failed client and true flag remain cached. Later diagnostics reuse an unstarted client without retrying. Concurrent first-use callers can also invoke the client before startup finishes. ### Steps to Reproduce Startup failure: 1. Arrange for the first remoting client's `start()` to throw a transient exception. 2. Trigger a proxy-connected consumer diagnostic query. 3. Clear the transient failure and query again. 4. Check whether a fresh client is started or the failed client is reused. Concurrent first use: 1. Hold the first client's `start()` pending. 2. Trigger a second query. 3. Check whether `invokeSync` runs before startup completes. ### What Did You Expect to See? Publish a reusable client only after startup succeeds. Concurrent first-use queries must not use a partially started client. Dispose failed candidates and allow a later retry, with a short failure backoff. Shutdown must not wait indefinitely for a blocked startup, and a startup completing after destruction must not publish or leak its client. ### What Did You See Instead? The reported code retains the failed client and ready flag after startup failure. Later diagnostics skip initialization even after the transient problem clears; a concurrent query can reach a client that is still starting. ### Additional Context ### Existing fix and review status The [October 10 maintainer review](https://github.com/apache/rocketmq-dashboard/pull/5255#pullrequestreview-5478050047) requested shutdown/startup coordination, failure backoff, and removal or justification of the redundant started flag. The [published response](https://github.com/apache/rocketmq-dashboard/pull/5255#issuecomment-6096850463) records all three changes at the current head: - A separate short lifecycle monitor coordinates destruction and publication without being held across `start()`; late candidates are disposed. - One-second failure backoff uses a controlled monotonic clock in tests. - `clientStarted` is removed; a non-null published client means startup succeeded. Three new regressions failed on the previous production implementation. The final focused matrix passed **102/102 tests**, with zero failures/errors/skips, zero Checkstyle violations and a clean diff check: `ProxyConsumerResolverTest,RocketMQAdminClientImplTest,RocketMQConsumerDiagnosticsProviderTest`. The published tree matched the locally tested tree and received independent review. No subsequent maintainer re-review or merge has been recorded. ### CI and verification limits [Current-head CI run 38046754975](https://github.com/apache/rocketmq-dashboard/actions/runs/38046754975) completed: - Backend Tests: **3439/3439 passed**. - Frontend Build, Frontend Docker Build and rmqctl Build: passed. - Backend Build: failed at the binary-license gate because complete upstream LICENSE/COPYING and original Spring Boot loader legal resources are missing. **Overall CI is not green.** No fresh local full-suite or external-datasource integration run is claimed. The license-material issue remains separate from this resolver fix. ### Scope and related reports This continuation covers only failed remoting-client startup and first-use publication/lifecycle handling. #5128 concerns cached Proxy addresses after endpoint changes; #2807 concerns transient Proxy-address discovery failure. They do not replace this report. AI assistance was used for the prior investigation, implementation and regression validation, and for preparing this tracking continuation. ### 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]
