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

   ### 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
   
   branch: `rocketmq-studio`
   git commit id: `1ef5d860` (upstream tip at the time of the report)
   deployed as: built from source
   
   ### Runtime Environment
   
   Verified by code tracing and unit tests on `rocketmq-studio` @ `1ef5d860` 
(vitest for `web/`, JUnit for `server/`), not against a specific browser or 
deployment.
   
   ### Connected RocketMQ Cluster
   
   Not cluster-specific: the defect lives in the code path and reproduces on 
any deployment where the trigger condition below holds.
   
   ### Describe the Bug
   
   Instance creation is check-then-act: `requireUniqueInstanceName` runs before 
the insert without any lock, and the `uk_instance_name` unique-key violation 
from a racing create is not translated. Only the cloud-credential foreign key 
case is mapped.
   
   ### Steps to Reproduce
   
   1. Two tabs (or a retry racing a slow first submit) POST 
`/api/instances/create` with the same instance name.
   2. Both pass `requireUniqueInstanceName`; the first insert wins.
   3. The second request returns an opaque 500 internal error instead of the 
duplicate-name error.
   
   ### What Did You Expect to See?
   
   The losing create returns the same duplicate-name error as the sequential 
case so the UI can surface an actionable message.
   
   ### What Did You See Instead?
   
   A raw 500 for a routine duplicate-name collision.
   
   ---
   
   Fix PR: #4936
   
   
   ---
   
   Re-submission: the original report (#4937) was closed by the stale bot after 
7 days without triage activity, and GitHub now rejects reopening items in this 
repository. Refiled unchanged; the fix PR is linked below.
   


-- 
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