Frun1na opened a new issue, #6100: URL: https://github.com/apache/rocketmq-dashboard/issues/6100
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `5e4c39b0` deployed as: reproduced by unit tests against that commit (the affected code is the backend instance service) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is the missing input bound, reproduced in a JUnit 5 service/controller test browser: not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — the batch delete targets Studio's own instance registry access mode: not applicable deployment: not applicable ### Describe the Bug `POST /api/instances/delete-batch` accepts a list of instance ids with no upper bound: - `BatchDeleteInstancesDTO.ids` (`server/src/main/java/org/apache/rocketmq/studio/instance/BatchDeleteInstancesDTO.java:26`) declares `@NotEmpty` only. - `InstanceService.deleteInstances` (`server/src/main/java/org/apache/rocketmq/studio/instance/InstanceService.java:738`) iterates the list and calls `self.deleteInstance(resolveInstanceId(id))` per entry, i.e. one identifier lookup and one transaction (each taking the instance lock, deleting the ownership claims and releasing the pooled Apache clients) per id. Every other batch input in the repository is capped at 100, on the request DTO and again in the service: `ImportTopicsDTO` / `MetadataService.importTopics`, `ImportConsumerGroupsDTO` / `MetadataService.importConsumerGroups` and `DLQResendSelectedRequestDTO` / `DLQService.resendSelectedMessages`. The batch delete is the only one without the bound, so a client can hand the server a list whose processing outlives any reasonable request timeout; the response that carries the per-id report never arrives, and which instances were actually deleted cannot be read from the UI. The console itself only submits the rows of one page, so the bound costs no existing flow anything. ### Steps to Reproduce 1. `POST /api/instances/delete-batch` with 1000 ids (no console flow is needed): ```json {"ids": ["inst-1", "inst-2", "...", "inst-1000"]} ``` 2. Or run the regression tests: ``` cd server && mvn -B -ntp test -Dtest=InstanceControllerTest,InstanceServiceTest ``` ### What Did You Expect to See? `400 Bad Request` naming the limit, the way the import and DLQ batch endpoints already answer. ### What Did You See Instead? The request is accepted and the server starts one lookup and one transactional delete per id; the response only arrives after the whole list has been processed. ### Additional Context A fix with regression tests follows in a pull request. ### 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]
