You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "unbridled-41 (via GitHub)" <gi...@apache.org> on 2026/09/21 19:19:37 UTC
[PR] fix(cluster): block duplicate NameServer registry submits while one is in flight [rocketmq-dashboard]
unbridled-41 opened a new pull request, #4794:
URL: https://github.com/apache/rocketmq-dashboard/pull/4794
Fixes #4793.
## Problem / Evidence
The NameServer registry create/edit modal keeps its OK button enabled for the whole request: `handleNsSubmit` has no in-flight guard and the modal has no `confirmLoading`, unlike the sibling connect (`confirmLoading={connectTesting}`) and config (`confirmLoading={configSubmitting}`) modals on the same page. A second 确认 click while the create is on the wire re-validates the (still-filled) form and POSTs the same registry entry again — two identical NameServer registry rows appear, each address then renders as its own cluster in the registry tables and the clients page's NameServer dropdown. The same window applies to edits, where two concurrent edits of one entry interleave last-write-wins.
Line references in the linked issue are as of trunk `4c697f07`; references below are as of the patched file at this PR's head.
## Root cause / Fix
`handleNsSubmit` now guards re-entry with an `nsSubmittingRef` (ref, so the async handler reads current state) plus an `nsSubmitting` state wired to `confirmLoading`, matching the pattern the page's other modals already use. The guard is released in `finally` so a failed request restores the button.
## Priority
PRIORITY 66 / 100 — impact 24 (duplicate persistent registry entries from a routine double-click; cleanup requires manually finding and deleting the twin), blast radius 12 (registry create + edit on the cluster page; feeds registry tables and the clients NameServer filter), reproducibility 18 (deterministic with any slow create request), maintenance value 12 (aligns the last unguarded modal on the page with its own established confirmLoading pattern). FIX_CONFIDENCE 90: same-page precedent, two-line guard, behaviour fully pinned by a test.
## Tests
- `ClusterPage.test` › `ignores extra confirm clicks while a NameServer create is in flight` (new): with the create deferred, one click posts once; two further clicks post no more; after the promise resolves the modal closes with the call count still 1.
- Teeth, measured on this machine: with only the test change on trunk source the test fails — after flushing the handler's microtasks, `createNameserverRegistry` was called twice (`Expected: 1, Received: 2`); with the fix, `ClusterPage.test` is 30/30.
- `npx tsc -b` clean, `npx eslint` on both changed files clean.
## Risk
Low. The guard only suppresses re-entry while the request is in flight; the failure path releases it so a rejected create can be retried immediately. No API or data-shape changes.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] fix(cluster): block duplicate NameServer registry submits while one is in flight [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins merged PR #4794:
URL: https://github.com/apache/rocketmq-dashboard/pull/4794
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org