[I] Allow explicit removal of unreachable instance registrations [rocketmq-dashboard]

["tju-yxq (via GitHub)" <gi...@apache.org>]

tju-yxq opened a new issue, #2210:
URL: https://github.com/apache/rocketmq-dashboard/issues/2210

   ## Problem
   
   Studio refuses to delete an instance registration until it can confirm through the selected vendor provider that the instance has no managed Topics or Consumer Groups:
   
   ```java
   int topicCount = provider.countTopics(id);
   int consumerGroupCount = provider.countGroups(id);
   ```
   
   That guard is necessary when the remote system is reachable, but it also makes a stale registration impossible to remove when the preflight cannot run. Examples include a decommissioned NameServer or Proxy endpoint, expired cloud credentials, a deleted cloud instance, DNS/network failure, or a provider API outage. In those cases `countTopics` or `countGroups` throws before `instanceRepository.deleteById` is reached.
   
   This conflicts with the UI's cloud-instance wording that deletion only removes the Studio registration and does not release the cloud RocketMQ instance. A registration whose remote instance is already gone can remain permanently stuck in Studio.
   
   ## Reproduction
   
   A deterministic service test against the current `rocketmq-studio` head (`eb44e159`) stubs an existing instance and makes `countTopics` throw `IllegalStateException("broker unavailable")`.
   
   Observed behavior:
   
   - the provider exception escapes;
   - `instanceRepository.deleteById` is never called;
   - no existing request option permits removal of the stale registration.
   
   This is a unit-level reproduction; it does not claim a live Broker or cloud-provider test.
   
   ## Required safety contract
   
   A force option must not turn the existing managed-resource guard into an unconditional bypass.
   
   1. A normal delete continues to run the authoritative provider preflight.
   2. If the preflight succeeds and finds any Topic or Consumer Group, deletion returns a conflict. Supplying `force=true` must not override this known result.
   3. If the preflight succeeds and both counts are zero, deletion proceeds normally.
   4. If the preflight cannot determine the counts, the normal request returns a stable machine-readable error distinct from the managed-resource conflict.
   5. Only after that specific failure may the UI offer a second, explicit warning that removes the Studio registration without claiming to delete or validate remote resources.
   6. A force request must still attempt the preflight. It may proceed only when that attempt is unavailable; it must still reject known managed resources.
   7. A forced removal must be visible in the operation audit, including `forced=true`, an unavailable-preflight marker, and a bounded/sanitized failure summary that cannot copy credentials or unbounded provider text into the audit record.
   8. Existing concurrent-delete behavior, Apache AdminClient release rules, and the 404 result for an already removed registration must remain intact.
   
   ## API and UI contract
   
   Use an instance-specific delete request instead of adding `force` to the common delete DTO used by unrelated resources.
   
   The backend response for an unavailable preflight needs a stable error identifier, so the frontend does not inspect an English message substring. The instance page should:
   
   - send the ordinary delete request after the existing confirmation;
   - show the second destructive confirmation only for the unavailable-preflight identifier;
   - never offer force removal for the managed-resources conflict;
   - resend the request with `force=true` only after explicit confirmation;
   - report a failure if the forced request itself does not complete.
   
   ## Tests
   
   Backend coverage should include:
   
   - empty-instance normal deletion;
   - Topics and Consumer Groups blocking both normal and force requests;
   - unavailable preflight rejecting a normal request without repository/audit side effects;
   - unavailable preflight allowing an explicit force removal;
   - sanitized and bounded forced-audit detail;
   - Apache endpoint release after a successful forced removal;
   - concurrent deletion still returning 404;
   - controller request binding and the machine-readable unavailable-preflight response.
   
   Frontend coverage should include:
   
   - force serialized in the instance API request;
   - the second confirmation appears only for the exact error identifier;
   - confirming it sends `force=true`;
   - ordinary conflicts and unrelated failures never expose the force path;
   - successful deletion still reloads the latest active filters.
   
   ## Related work
   
   - #1235 introduced the authoritative live-count preflight; this issue preserves that protection.
   - #1726 concerned converting one unsupported Tencent count path into an HTTP 501 response. It was closed because `UnsupportedOperationException` already had a handler. A structured failure alone does not provide an explicit, safe way to remove a stale registration.
   - #2000 covers the separate concurrent-delete zero-row result.
   - #1592 implements Tencent group counting and does not address unreachable/decommissioned providers.
   
   The expected implementation spans the instance-specific backend request/error/preflight/audit contract and the frontend API/confirmation flow. The production change is expected to exceed 100 lines because both boundaries must change together; tests are not counted toward that estimate.
   
   


-- 
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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Allow explicit removal of unreachable instance registrations [rocketmq-dashboard]

["github-actions[bot] (via GitHub)" <gi...@apache.org>]

github-actions[bot] closed issue #2210: Allow explicit removal of unreachable instance registrations
URL: https://github.com/apache/rocketmq-dashboard/issues/2210


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Allow explicit removal of unreachable instance registrations [rocketmq-dashboard]

["github-actions[bot] (via GitHub)" <gi...@apache.org>]

github-actions[bot] commented on issue #2210:
URL: https://github.com/apache/rocketmq-dashboard/issues/2210#issuecomment-5376658321

   This issue has been automatically closed because there has been no activity for 7 days. If you believe this issue is still relevant, please reopen it with updated information.


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Allow explicit removal of unreachable instance registrations [rocketmq-dashboard]

["RockteMQ-AI (via GitHub)" <gi...@apache.org>]

RockteMQ-AI commented on issue #2210:
URL: https://github.com/apache/rocketmq-dashboard/issues/2210#issuecomment-5295483406

   **Issue Evaluation**
   
   Category: `enhancement` | Status: **Evaluated**
   
   **Feasibility:** Feasible
   **Scope:** `InstanceService`, `InstanceController`, Studio UI instance management
   **Compatibility:** Additive — new `force` query parameter; existing delete semantics unchanged
   
   The analysis is accurate. The current preflight in `InstanceService` calls `provider.countTopics(id)` / `provider.countGroups(id)` before `instanceRepository.deleteById`, which means any provider unavailability (decommissioned endpoint, expired credentials, DNS failure) permanently traps the registration. The proposed 8-point safety contract is well-designed:
   
   1. Normal delete keeps the authoritative preflight ✓
   2. `force=true` does NOT bypass known managed-resource conflicts ✓
   3. Force only activates when preflight is *unavailable*, not when it reports resources ✓
   4. Distinct machine-readable error for unavailable-preflight vs conflict ✓
   5. Audit trail with `forced=true` and sanitized failure summary ✓
   
   This is a clean improvement that resolves a real operational pain point. The safety contract correctly prevents `force` from becoming an unconditional bypass.


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org