zmuxuny opened a new issue, #5049: URL: https://github.com/apache/rocketmq-dashboard/issues/5049
### Before creating the bug report - [x] Searched open and closed issues/PRs for Aliyun client invalidation, credential cache races, and `AliyunClientFactory`. #1212/#1213 added invalidation after credential changes; this race remains in that invalidation path. #4755/#4761 concerns the separate RocketMQ admin/client pools. - [x] Reproduced on current `rocketmq-studio` at `0228dad5` using a deterministic concurrency test. ### Studio version and runtime `rocketmq-studio` commit `0228dad5`; Java 21 unit test with mocked Aliyun clients. No RocketMQ cluster, cloud account, browser, or MySQL is needed to reproduce the cache race. ### Problem and reproduction `CloudCredentialService.update` persists a rotated Aliyun secret and calls `AliyunClientFactory.invalidateCredential(id)`. At the same time another request may be creating the first cached client for that credential/region: 1. Start `AliyunClientFactory.client(id, region)` and pause inside `createClient` after it has read the old secret, before `computeIfAbsent` publishes the client. 2. Call `invalidateCredential(id)` after the credential update. It iterates the cache and returns while the client is still being created. 3. Let creation finish and call `client(id, region)` again. The second lookup returns the old client, which was inserted after invalidation and therefore continues signing requests with the previous secret until another invalidation or process restart. The credential update reports success, so this can make subsequent cloud operations fail with an invalid-credential error despite the new secret being stored. ### Expected behavior A lookup started after invalidation completes should construct a client from the updated credential. A client still being created during invalidation must not remain cached afterward. ### Actual behavior and evidence A new `AliyunClientFactoryTest.invalidateCredentialShouldEvictClientCreatedDuringRotationTest` was run against the unmodified production code. It fails on the final lookup: the returned client is the old mock, not the replacement mock. Checkstyle passes. The analogous Tencent factory coordinates creation and invalidation under the same monitor and already has a regression test for this case. This report concerns cache publication during rotation. It does not claim that the current factory safely waits for *already active* OpenAPI requests before closing a client. I can submit a focused fix and regression test. -- 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]
