unbridled-41 opened a new issue, #4793:
URL: https://github.com/apache/rocketmq-dashboard/issues/4793
### Studio Version
Trunk `rocketmq-studio` @ `4c697f07` (line references are as of that commit).
### Problem
The NameServer registry create/edit modal
(`web/src/pages/cluster/index.tsx:1854-1863`) wires `onOk` straight to
`handleNsSubmit` with neither `confirmLoading` nor an in-flight guard.
`handleNsSubmit` (`index.tsx:284-316`) is async and only closes the modal after
`createNameserverRegistry`/`updateNameserverRegistry` resolves, so the OK
button stays clickable for the whole network round trip. Every other submitting
modal on the same page wires `confirmLoading` (connect modal:
`confirmLoading={connectTesting}`; config modal:
`confirmLoading={configSubmitting}`); this one was missed.
### Evidence
1. `handleNsSubmit` awaits `nsCreateForm.validateFields()` and then the
create/update call; the modal only closes in the success branch. A second OK
click during the await re-enters the handler, re-validates (fields are still
filled) and issues a second identical POST.
2. The backend `createNameserverRegistry` endpoint accepts any unique
name/address pair, so two identical submissions create two registry entries —
`rmq_nameserver` has no unique constraint on (`name`, `namesrv_addr`) that
would deduplicate a client double-click (the migration at
`deploy/mysql/upgrade-nameserver-name-uk.sql` only covers the name key).
3. Measured in this sandbox: with a deferred create promise, clicking 确认
twice posts twice (test red on trunk source, green with the fix).
### Impact
Duplicate NameServer registry entries appear in the cluster registry, each
address then renders as its own cluster in the registry tables and the clients
page's NameServer dropdown; the operator has to find and delete the twin
manually. The same window applies to edits, where the last write wins and can
interleave two different edits of the same entry.
### Expected behavior
While a create/update request is in flight, the OK button shows the request
state (confirmLoading) and further clicks are ignored — the same contract every
other submitting modal on the page already implements.
### Related work
- #4618 (open): per-loader error state in the same page's registry loaders;
unrelated to the modal.
- #4559 (open): registry config-update scoping; different modal, same page.
- #4754 (merged): the only prior duplicate-submission report family is the
AI composer; no existing issue tracks the registry modal.
## PR
Fix: #… (opened together with this issue).
--
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]
