pilichoumao opened a new issue, #6513: URL: https://github.com/apache/rocketmq-dashboard/issues/6513
### Before Creating the Bug Report - [x] Searched open issues and PRs for rmqctl concurrent config mutation / lost context updates. ### Describe the Bug `config set-context`, `use-context` and `delete-context` load a configuration snapshot and later save it. Two processes can load the same old snapshot, make independent mutations, and both report success while the later save discards the earlier update. `Store.Save` already atomically replaces a complete document and should retain that contract. The missing boundary is the complete command-level read/modify/save transaction. ### Steps to Reproduce At `rocketmq-studio` commit `779b8c0e`, two independent Linux child processes using the production `Store.Load`/`Store.Save` path both read an empty config. Process A adds alpha and saves; process B then saves its stale snapshot with beta. Both saves succeed; the final file contains beta only. This controlled interleaving reproduced in three race-enabled runs on ECS. The initial reproduction uses a helper with the same mutation sequence, not two untouched CLI invocations. ### Expected Behavior Cooperating config mutation commands serialize the full transaction. A waiting command reloads the latest document after obtaining the lock, preserving other updates. Permission checks, strict YAML validation, environment-only credential references and existing whole-document Save behavior remain intact. ### Proposed Solution for Discussion - An internal `Store.Update(context.Context, path, mutate)` loads, mutates, validates and saves while holding an exclusive cross-process lock. - Persistent `<config>.lock` sidecar: atomic replacement cannot invalidate the lock inode; OS releases the lock on process exit. Do not delete the sidecar after unlocking. - Canonicalize the absolute parent directory (including directory symlinks) so equivalent path spellings share a lock. - Use `github.com/gofrs/flock` for native Linux/macOS/Windows locking, with 0600 sidecar permissions, a bounded 30-second wait and command cancellation. Unsupported/failed locking must return an error, not save unlocked. - Keep read-only commands lock-free and preserve Store.Save's full replacement semantics. External editors and old binaries do not participate in the protocol. This targets local filesystems; network-filesystem lock guarantees are outside the proposal. - Validate process contention, current-context/delete behavior, invalid YAML and callback rollback, cancellation/timeouts, lock release after process death, Linux/macOS runtime and Windows cross-build/CI runtime. Alternatives: a process-local mutex cannot serialize independent processes; locking only Rename still permits stale snapshots; exclusive-create lock directories require a stale-lock recovery policy. A stable advisory sidecar avoids manual stale-lock deletion. ### Additional Context #6208 covers whole-document atomic Save behavior; it does not serialize command mutations. This proposal does not change the precedence logic of configuration paths or merge arbitrary saved documents. A draft implementation will provide concrete review material; design consensus is still pending. ### Are You Willing to Submit a Pull Request? - [x] Yes. -- 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]
