[BUG] <title> admin can't delete upstream success

[hengyuss]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

now if you delete a upstream on admin, but bootstrap still cache the upstream.

Expected Behavior

bootstrap should delete the upstream too.

Steps To Reproduce

No response

Environment

ShenYu version(s): latest

Debug logs

No response

Anything else?

I will fix it

[hengyuss]

/assign

[github-actions]

👋 Hello @yuluo-yx

A new issue has been opened by @hengyuss:

• Title: [BUG] <title> admin cont't delete upstream success
• Link: [BUG] <title> admin can't delete upstream success #7165

Please review when you have time. Thank you! 🙏

[ywj1352]

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 discoveryHandlerIds 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.