zmuxuny opened a new issue, #6176: URL: https://github.com/apache/rocketmq-dashboard/issues/6176
### 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@5e4c39b0, verified 2026-10-10. ### Runtime Environment Deterministic frontend ConsumerPage.test.tsx regression with mocked API responses. No live production incident or live broker mutation is claimed. ### Connected RocketMQ Cluster Apache consumer-group settings represented by mocked API responses; no live cluster required for this UI state regression. ### Build Toolchain _No response_ ### Describe the Bug The Consumer Group Settings form keeps originalSettingsRef from its initial read after a successful save. Later edits in the same modal are compared with obsolete settings rather than the settings just saved. For a group initially configured with consumption disabled, an operator can enable consumption and save successfully, then disable consumption again in the same modal. The second save bypasses the existing destructive-change confirmation and directly sends the update because the baseline still says consumption is disabled. ### Steps to Reproduce 1. Open an Apache consumer group's Settings tab with consumeEnable=false. 2. Enable consumption and save successfully without closing the modal. 3. Disable consumption again and save. 4. Observe the update is submitted without the confirmation normally required for a true-to-false transition. ### What Did You Expect to See? After a successful save, change detection and risk confirmation use the last successfully submitted settings. Failed saves must not advance that baseline. ### What Did You See Instead? The second update is sent directly. A deterministic regression named requires confirmation when disabling consumption after enabling it in the same session fails against unchanged production source: Modal.confirm expected 1 call, received 0. Result: 1 failed, 47 skipped. ### Additional Context ### Evidence `web/src/pages/instance/consumer.tsx`: the settings read sets `originalSettingsRef` around line 532, but the successful save path around lines 559–612 does not update it. Regression command: `npm test -- src/pages/instance/__tests__/ConsumerPage.test.tsx -t 'requires confirmation when disabling'` This report concerns two sequential completed saves in one modal. It does not claim cross-group form contamination, a server-side authorization bypass, or a live production incident. No live broker mutation was performed. ### Duplicate check #2634 / #2637 / #2754 address out-of-order responses across modal sessions. #5495 clears failed inventory reloads. Neither updates the baseline after a successful settings save. Open PR and historical issue/PR searches for `originalSettings`, `consumeEnable` with confirmation, and consumer settings save confirmation found no equivalent fix. ### Acceptance criteria - Advance the baseline only after successful save, using the settings actually submitted. - Require the existing confirmation for a subsequent destructive transition. - Preserve the previous successful baseline after a failed save. - Cover repeated saves in one modal with regression tests. AI assistance was used for source inspection and deterministic regression authoring. ### 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]
