youngkermit8-coder opened a new issue, #7077: URL: https://github.com/apache/rocketmq-dashboard/issues/7077
### Before Creating the Bug Report - [x] I searched the open issues and related pull requests and believe this specific inter-call cancellation problem is not already tracked. - [x] This concerns RocketMQ Studio, not a usage question or another repository. - [x] The exact source version and controlled reproduction are stated below. ### Studio Version Built from source, `rocketmq-studio` at `70be77c5cbc9015fe9c866c8d1bbd3d087d9de32`. The subsequently inspected trunk `3d1641bad17ddd4c7a5d9fff7252dfc0028d7bf2` has the identical `InstanceService.java` blob (`462e188d652e9f057e65c1e98c7a02318cd1d8d3`). The full build results below belong to the earlier pinned snapshot, not to this newer whole trunk. ### Runtime Environment Controlled Java service/runner tests, not an observed deployed incident. The focused reproduction ran on Windows with Java 21; separate full-backend verification ran on Linux/Java 21 with an isolated MySQL 8.0.46 and the unchanged source schema. Existing H2/mock test boundaries were retained. ### Connected RocketMQ Cluster No live cluster or cloud account was contacted. The real `InstanceService` and `InstanceResourceCountRunner` were used with latch-controlled `InstanceProvider` mocks. The cancellation cases use an Aliyun provider identity; healthy controls cover all three vendor enum values. This does not establish how frequently any real SDK exhibits the condition. ### Build Toolchain Java 21, Maven 3.9.9. No dependency or executor configuration changes are proposed. ### Describe the Bug `InstanceService.loadCounts` unconditionally starts `countGroups` after `countTopics`. If the first call returns late after the batch deadline or caller cancellation, while preserving the worker's interrupt flag, the second provider lookup still starts even though the caller has stopped waiting. The detached unavailable response is already protected from late mutation by #3044. This report concerns avoidable follow-on work, not response corruption or a replacement executor policy. ### Steps to Reproduce 1. Return one instance from a mocked repository and resolve its provider through the normal registry. Call `listInstances(null, null, true)` on a separate caller thread using the actual service/runner. 2. Make `countTopics` signal a `started` latch and block on a `release` latch. If interrupted while blocked, remember the interruption, continue waiting, and restore the interrupt flag immediately before returning a count. 3. After `started`, either let the existing three-second deadline expire or interrupt the caller. Wait for the caller to return an unavailable count response before releasing the provider. 4. Release the first lookup and wait for the count worker to become idle. Verify that the worker returned with its interrupt flag set, then assert `verify(provider, never()).countGroups(instanceName)`. On the pinned unchanged production source, both cancellation assertions fail with Mockito `NeverWantedButInvoked`: `countGroups` was called. Three separate healthy-vendor controls pass. This is a controlled provider model that preserves interruption, not evidence that an already-running I/O call can be forcibly stopped. The existing `InstanceServiceTest` late-result test uses a similarly interruption-preserving provider. Its `countGroups` completion latch currently also demonstrates that the second lookup is reached after timeout; a regression for this report should await worker completion independently instead of requiring that unwanted call. ### What Did You Expect to See? If the worker is still interrupted when the first lookup returns, avoid admitting the second lookup. Keep the caller's existing unavailable response and the healthy two-lookup behavior unchanged. ### What Did You See Instead? The second lookup starts after the timed-out/interrupted batch has returned. On the tested snapshot this occurs in both controlled cancellation scenarios. ### Additional Context Would a cooperative interrupt checkpoint between the two existing provider calls, using the runner's existing failure path, be an appropriate narrow follow-up to #3044? It would not terminate already-started I/O, detect an interrupt cleared by a provider, or make cancellation atomic with dispatch. Related work inspected before opening this report: - #3044 implements bounded count lifetime and response isolation; credit to its original author. - Open #6978 cancels queued futures during runner shutdown, not this running service's inter-call lookup. - Open #6775 fixes the availability sentinel on unmeasured create/update responses, not cancellation. It shares an existing test file but changes different behavior. A local prototype was investigated before this issue was opened; I am asking for direction before submitting its code as a PR. On the pinned `70be77c5` snapshot, the proposed checkpoint passed 110 related executions and a separate unfiltered backend run of 307 suites / 3,794 executions with no failures, errors or skips, followed by normal packaging and Checkstyle. These are local results, not official CI or verification of the newer complete trunk. Three pre-existing material warnings were retained. An earlier supplemental diagnostic failed at the Docker connection boundary and is not claimed as a valid Linux scenario result. AI assistance was used for investigation, prototype implementation and verification. No credentials, customer data, raw diagnostic logs or binaries are included. ### Are You Willing to Submit a Pull Request? - [x] Yes, subject to the project's feedback and a fresh pre-submission validation. -- 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]
