zmuxuny opened a new issue, #6762:
URL: https://github.com/apache/rocketmq-dashboard/issues/6762

   ### 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
   
   rocketmq-studio at a92c23144408cdf5729707050e9ecd9b75f1bad0
   
   ### Runtime Environment
   
   Linux, Node 24.19.0, repository Vitest/jsdom ConsumerPage tests with mocked 
consumer services. No live cluster operation.
   
   ### Connected RocketMQ Cluster
   
   Not required: deterministic frontend service-mock reproduction.
   
   ### Build Toolchain
   
   _No response_
   
   ### Describe the Bug
   
   When the first consumer-group settings read fails, the editor becomes 
editable and Save remains enabled despite having no successfully loaded 
settings baseline. Filling the required retry fields can send an update built 
from an uninitialized form. Returning to Settings does not retry because 
settingsGroup was assigned before the failed read.
   
   ### Steps to Reproduce
   
   1. Open a consumer group detail and select Settings.
   2. Make getConsumerGroupSettings reject.
   3. After the load-failed message, enter retry queue count 1 and max retries 
16; toggle consumption on and off.
   4. Click Save.
   A regression test at the stated commit observes one 
updateConsumerGroupSettings call. A successful-read/edit control passes.
   
   ### What Did You Expect to See?
   
   Keep the form and Save unavailable until a current settings read succeeds, 
guard the save handler, and provide a retry path after a read failure. A late 
read from a closed detail session must not unlock a newer session.
   
   ### What Did You See Instead?
   
   The service receives an update containing consumeEnable:false, 
retryQueueNums:1 and retryMaxTimes:16 even though the initial read failed. The 
save logic has no loaded original settings to compare. Save is also enabled 
during the pending initial read, and no in-place retry is available after 
failure.
   
   ### Additional Context
   
   Four tests-only regressions fail on the stated baseline; the existing 
successful-read/edit control passes. Related #6176/#6182 concern advancing the 
baseline after a successful save; this case never obtains an initial baseline. 
#6722 concerns form-validation rejection. Proposed fix will preserve 
request-generation ownership and optional response fields.
   
   ### 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