xuxiaowei-com-cn opened a new issue, #8174: URL: https://github.com/apache/incubator-seata/issues/8174
### Check Ahead - [x] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate. - [x] I am willing to try to fix this bug myself. ### Ⅰ. Issue Description `ConfigurationChangeListenerTest.testCachedConfigurationChangeListener()` is a **flaky test** that fails intermittently in CI and local environments: ``` [ERROR] Failures: [ERROR] ConfigurationChangeListenerTest.testCachedConfigurationChangeListener:234 expected: <true> but was: <false> ``` https://github.com/apache/incubator-seata/actions/runs/29933243660 <img width="2092" height="1230" alt="Image" src="https://github.com/user-attachments/assets/2889ef41-c86d-4b9d-a0b9-22f57227b65d"; /> ### Ⅱ. Describe what happened The test asserts `changeEventCalled.get()` returns `true`, but it returns `false` intermittently. **Root cause:** The default implementation of `ConfigurationChangeListener.onProcessEvent()` submits the `onChangeEvent()` callback to a thread pool **asynchronously** via `getExecutorService().submit(...)`, and the method returns immediately: ```java // config/seata-config-core/src/main/java/org/apache/seata/config/ConfigurationChangeListener.java:63-69 default void onProcessEvent(ConfigurationChangeEvent event) { getExecutorService().submit(() -> { // ⚠️ async submission beforeEvent(event); onChangeEvent(event); afterEvent(event); }); } ``` The test code before the fix was synchronous: ```java listener.onProcessEvent(event); // async submission, returns immediately Assertions.assertTrue(changeEventCalled.get()); // ❌ race: callback may not have executed yet ``` There is a **race condition** between the test thread and the thread-pool worker. Most of the time the pool executes the callback quickly enough for the test to pass, but under CI load or scheduling delays, the assertion runs before the callback, causing the failure. ### Ⅲ. Describe what you expected to happen The test should pass deterministically, unaffected by thread scheduling timing. ### Ⅳ. How to reproduce it (as minimally and precisely as possible) 1. Run the test on a CI environment or a machine under load: ```bash mvn test -pl config/seata-config-core -Dtest=ConfigurationChangeListenerTest#testCachedConfigurationChangeListener ``` 2. Run it repeatedly (e.g., in a loop with `-DfailIfNoTests=false`) to surface the intermittent failure. 3. Error message: `expected: <true> but was: <false>` ### Ⅴ. Anything else we need to know? **Fix approach:** Use `CountDownLatch` to synchronously wait for the async callback (commit f1cf46c3): 1. Call `latch.countDown()` inside the `onChangeEvent()` callback to signal the test thread. 2. Call `latch.await(5, TimeUnit.SECONDS)` to wait up to 5 seconds. 3. The timeout acts as a safety net to prevent the test from hanging indefinitely in edge cases. ### Ⅵ. Environment - JDK version: any - Seata client/server version: 2.x - OS: any (higher reproduction rate on CI / constrained environments) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
