ywj1352 commented on issue #7165: URL: https://github.com/apache/shenyu/issues/7165#issuecomment-5773069562
# I. Logic Summary (The Complete Truth of This Sync Chain) **Core mechanism:** discovery upstream synchronization follows a "full-snapshot UPDATE" model — after each change, the admin side reads out the entire remaining upstream group via `fetchAll`, publishes a `DISCOVER_UPSTREAM / UPDATE` event, and the gateway's `onSubscribe → submit()` replaces the whole group. Deletion = absence from the new list; an empty list automatically clears the cache. ## Actual status of each deletion scenario | Scenario | Chain | Status | |---|---|---| | External instance offline | `DiscoveryDataChangedEventSyncListener`: deletes DB rows, then unconditionally publishes the remaining snapshot | ✓ Working | | Client registration offline | `offline() → fetch() → UPDATE` | ✓ Working | | Health-check removal | `UpstreamCheckService → UPDATE filtered snapshot` | ✓ Working | | Selector deletion | SELECTOR-group DELETE fallback → `removeByKey` | ✓ Working (via fallback) | | Manual single-upstream deletion (console) | `delete()` only deletes DB rows, publishes no event | ✗ The only real bug, since 2023 | | Rebind / delete selector-level discovery | DELETE event swallowed by empty `unSubscribe`; zk channel lacks the DELETE branch entirely | ✗ Defensive gap | **Final verdict on the empty `unSubscribe`:** it is a contract method copied from the subscriber-family template. Its only real traffic comes from `removeSelectorUpstream` — which is in turn masked by the fallback. Zero actual damage in three years: it is a "never-truly-used contract", not the scene of an incident. # II. Fix Recommendation (Step 1 already implemented and compiling clean) - **Step 1 (do now):** fix `DiscoveryUpstreamServiceImpl.delete` to publish the remaining-list snapshot after deletion, symmetric with create/update — collect the affected `discoveryHandlerId`s *before* deleting (they cannot be queried afterwards), delete the rows, then call `fetchAll` once per group. Zero interface changes, all nine sync channels covered for free, +7 lines in one file. - **Step 2 (follow-up, not urgent):** complete the DELETE consumer chain — add a `default` remove hook to `DiscoveryUpstreamDataHandler`, implement it per plugin (divide/websocket → `removeByKey`, grpc → `ApplicationConfigCache.invalidate`, tcp → `refreshCache` with an empty list), route `unSubscribe` to it, and add the missing DELETE branch to `discoveryUpstreamHandlerEvent` for the zk/etcd/consul path. Defensive hardening — wait for upstream feedback or a real-world report of the rebind scenario. -- 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: notifications-unsubscr...@shenyu.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
