wy471x commented on PR #7395: URL: https://github.com/apache/shenyu/pull/7395#issuecomment-5930653492
**Verified independently on JDK 21 — LGTM** I reproduced both the failure and the fix locally: **Static verification** - `DataChangedEventDispatcher.dispatch()` invokes the 3-arg overload (`DataChangedEventDispatcher.java:115`), and the 3-arg default method delegates to the 2-arg one (`DataChangedListener.java:74-76`). Since the listeners are plain `@Mock`s, Mockito never executes the default body, so the old 2-arg `times(1)` verifications could not match and the `never()` ones were vacuously true. - Repo-wide check: no other mock-based verifications of the namespace-aware methods are left behind; the remaining 2-arg verifications in this file target methods that only have a 2-arg overload (`onMetaDataChanged`, `onProxySelectorChanged`, `onAiProxyApiKeyChanged`, `onDiscoveryUpstreamChanged`), so they are unaffected. - The aligned `never()` assertions are now meaningful: `HttpLongPollingDataChangedListener` extends `AbstractDataChangedListener` (still dispatched when not master), while the nacos/websocket/zookeeper listeners do not (skipped when not master), so both the positive and negative expectations hold. **Test runs (`shenyu-admin`, JDK 21)** - pre-PR master: `Tests run: 18, Failures: 3` — exactly the failures listed in #7393 (lines 343/359/372). - with this PR applied: `Tests run: 18, Failures: 0, Errors: 0`, Checkstyle: 0 violations. **Non-blocking suggestion** These tests assert which overload the dispatcher invokes, but the 3-arg → 2-arg default delegation path and namespaceId propagation remain uncovered. A small `spy` / `CALLS_REAL_METHODS` case could guard against a future signature change, but that is out of scope here. Thanks @eye-gu — the follow-up commit covering the two `never()` checks in the transaction tests was the right call. -- 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]
