coder999o opened a new issue, #7349: URL: https://github.com/apache/rocketmq-dashboard/issues/7349
### Before Creating the Bug Report - [x] Searched open and closed Issues, all-state PRs and their relevant patches. - [x] This is a RocketMQ Studio defect. - [x] Confirmed the update/locking order on the current rocketmq-studio source. ### Studio Version `rocketmq-studio` at `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, built from source. ### Runtime Environment Source-level reproduction of the transactional Java service and JDBC locking path. The normal deployment uses MySQL. A focused H2 test will exercise the interleaving; no deployed MySQL reproduction is claimed here. ### Connected RocketMQ Cluster Not required: the failure concerns persisted instance metadata before any broker operation. ### Describe the Bug `InstanceService.updateInstance` reads an instance, copies its metadata, applies the supplied fields, and then calls `ResourceOwnershipGuard.lockForInstanceUpdate` before saving the full copy. The lock checks that the current name, endpoint, credential reference, type and vendor still match the earlier snapshot, but does not check the remark. An overlapping remark-only update can commit after another update reads the row and before it acquires that lock. The older request passes the guard and saves its old remark, undoing an update that already succeeded even though its own request did not include a remark. ### Steps to Reproduce 1. Create an unoccupied Apache instance with endpoint `old:9876` and remark `original`. 2. Start request B through `/api/instances/update` with its ID and endpoint `new:9876`, omitting the remark. Pause after `findById` returns its snapshot and before the ownership lock. 3. Complete request A updating only the same instance's remark to `new remark`. 4. Resume B. Its connection/identity snapshot still matches the row, so it passes the lock and saves the copied instance. 5. Read the instance: B has restored `original`, losing A's successful remark change. The same ordering also affects overlapping remark-only edits. It does not require a failure from a broker or from the database. ### What Did You Expect to See? A stale full-row update should return the existing 409 conflict before save. Retrying from a fresh snapshot should preserve fields omitted from the request. A remark change should not invalidate unrelated resource writes whose connection identity remains current. ### What Did You See Instead? Both updates can succeed while the later save silently restores the older remark. ### Additional Context Compare remark freshness only for instance metadata updates, using the locked current row. Keep the existing resource-write connection checks unchanged. No API or schema change is needed; comparing a timestamp alone would miss changes within the database timestamp precision. ### 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]
