wy471x opened a new pull request, #7060: URL: https://github.com/apache/shenyu/pull/7060
<!-- Describe your PR here; e.g. Fixes #issueNo --> <!-- Thank you for proposing a pull request. This template will guide you through the essential steps necessary for a pull request. --> Make sure that: - [X] You have read the [contribution guidelines](https://shenyu.apache.org/community/contributor-guide). - [X] You submit test cases (unit or integration tests) that back your changes. - [X] Your local test passed `./mvnw clean install -Dmaven.javadoc.skip=true`. ## Summary Fixes #6661. Path-based sync services (etcd / zookeeper / consul, all extending `AbstractPathDataSyncService`) do receive delete notifications for discovery upstream nodes: `EtcdSyncDataService.watchChildChange` fires `super.event(configNamespace, deletePath, null, registerPath, EventType.DELETE)` (`EtcdSyncDataService.java:88`), and `event()` dispatches it to `discoveryUpstreamHandlerEvent`. But that handler only acted when the event was **not** a delete, so the DELETE was silently dropped and `DiscoveryUpstreamDataSubscriber#unSubscribe` was never called. Every other entity in the same class (plugin, selector, rule, app auth, meta data, proxy selector) already handles DELETE. ### Changes: 1. `AbstractPathDataSyncService.discoveryUpstreamHandlerEvent` (`AbstractPathDataSyncService.java:132`) — added the missing DELETE branch: parses `pluginName` and the last path segment with the same `split("/")` pattern used by `proxyHandlerEvent`, builds a `DiscoverySyncData` carrying them, and calls the new un-cache hook. The PUT path is unchanged. 2. `AbstractPathDataSyncService.unCacheDiscoveryUpstreamData` (`AbstractPathDataSyncService.java:290`) — new protected hook delegating to `discoveryUpstreamDataSubscribers.forEach(e -> e.unSubscribe(...))`, mirroring the existing `unCacheProxySelectorData` / `unCacheMetaData` helpers and the node-based counterpart `AbstractNodeDataSyncService.unCacheDiscoveryUpstreamData`. Note on the parsed path segment: the discovery-upstream path ends with the **selector id**, not the selector name — `AbstractPathDataChangedListener.onDiscoveryUpstreamChanged` builds it with `buildDiscoveryUpstreamPath(data.getNamespaceId(), data.getPluginName(), data.getSelectorId())`, and the node-based sync sets `selectorId` for the same reason. This PR therefore sets `selectorId` (the issue text suggested "selector name"). ### Test Cases: - `AbstractPathDataSyncServiceTest#testDiscoveryUpstreamHandlerEvent` (`AbstractPathDataSyncServiceTest.java:93`) — dispatches `event(...)` for `/{ns}/shenyu/discoveryUpstream/divide/{selectorId}`: PUT triggers `onSubscribe`, DELETE triggers `unSubscribe`, and the captured `DiscoverySyncData` carries `pluginName=divide` / `selectorId=testSelectorId`. ## Verification - `./mvnw clean install -Dmaven.javadoc.skip=true` on JDK 21: whole reactor passes, with the one pre-existing order-dependent test excluded (`-Dtest='!DubboReconcilerTest' -DfailIfNoTests=false`). `org.apache.shenyu.k8s.DubboReconcilerTest` shares the static `IngressCache` with `WebSocketReconcilerTest` / `DivideIngressReconcilerTest` (all use `mockedNamespace/mockedIngress`) and fails purely on test execution order: it passes in isolation and reproduces the same failure on unmodified `master`. `shenyu-kubernetes-controller` does not depend on `shenyu-sync-data-api`. - Touched module and its dependents: `shenyu-sync-data-api`, `shenyu-sync-data-etcd`, `shenyu-sync-data-zookeeper`, `shenyu-sync-data-consul` — all tests pass. - `checkstyle:check` — 0 violations. Not covered here: the gateway-side `CommonDiscoveryUpstreamDataSubscriber#unSubscribe` is still a no-op (`//ignore`), so actually evicting the cached upstream list (`UpstreamCacheManager.removeByKey(selectorId)`) on deletion remains a separate change in the discovery plugin handlers. @Aias00, could you please help review this PR? Thank you! close #6661 -- 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]
