X-LightYear opened a new issue, #4987:
URL: https://github.com/apache/rocketmq-dashboard/issues/4987

   ### Before Creating the Bug Report
   
   - [x] I searched the open and closed issues and believe this is not a 
duplicate.
   - [x] This is a defect in RocketMQ Studio.
   - [x] The behavior is reproducible on the current `rocketmq-studio` branch.
   
   ### Describe the Bug
   
   `PUT /api/instances/update` returns an `InstanceVO` assembled by
   `InstanceService.updateInstance`. The update path copies the stored instance
   through `copyOf`, but that copy omits the response fields `regionName` and
   `resourceCountsAvailable`.
   
   As a result, a direct API client receives a response that no longer describes
   the same instance state returned by the instance list endpoint:
   
   - a stored `regionName` is returned as `null`;
   - a stored unavailable-count state can be returned as the default `true`.
   
   The web page currently reloads the instance list after updating, which masks
   the problem in the console but does not fix the API response contract.
   
   ### Reproduction
   
   1. Have an instance whose list representation contains `regionName=Hangzhou`
      and `resourceCountsAvailable=false`.
   2. Send an update that changes only an editable field such as `remark`.
   3. Inspect the JSON response from `/api/instances/update`.
   
   ### Expected behavior
   
   The update response should preserve the non-persistent fields already present
   on the stored instance, including `regionName` and
   `resourceCountsAvailable`, unless the update operation intentionally changes
   them.
   
   ### Actual behavior
   
   `regionName` is `null`. `resourceCountsAvailable` is restored to the
   `InstanceVO` builder default instead of retaining the stored value.
   
   ### Regression evidence
   
   The deterministic unit test
   `InstanceServiceTest.updateInstanceShouldPreserveListOnlyFieldsInResponse`
   fails on the current production code because the returned `regionName` is
   `null` instead of `Hangzhou`.
   
   ### Scope
   
   The defect is confined to the response copy in `InstanceService.copyOf`; no
   database schema or RocketMQ broker behavior is involved.
   
   ### 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]

Reply via email to