Aias00 opened a new issue, #7815:
URL: https://github.com/apache/shenyu/issues/7815
### Is there an existing issue for this?
- [x] I searched existing open/closed issues.
- #6479 fixed propagation/handling of discovery DELETE events in
subscribers. This report is earlier in the chain: the Admin HTTP delete API
never publishes a change at all.
- #7791 covers stale targets when the shared cache receives a full non-empty
replacement; that is a separate downstream reconciliation problem.
### Current Behavior
`DELETE /discovery-upstream/batch` returns success after deleting database
rows, but does not publish the remaining upstream snapshot or notify the
gateway. A removed, still-reachable upstream can remain a routing candidate in
connected gateways.
The actual path is:
```text
DiscoveryUpstreamController.deleteDiscoveryUpstream
-> DiscoveryUpstreamServiceImpl.delete(ids)
-> discoveryUpstreamMapper.deleteByIds(ids)
-> DELETE_SUCCESS
```
The SQL mapper only deletes rows. The service does not resolve affected
discovery handlers, call fetchAll/changeUpstream, or publish a DataChangedEvent.
### Expected Behavior
A successful upstream delete should propagate the complete remaining list
for each affected handler, including an empty list when the last upstream is
deleted. Connected gateways should stop selecting the removed URL without
requiring another unrelated edit or reconnect.
### Steps To Reproduce
1. Configure a local Discovery-backed divide selector with one reachable
HTTP upstream. Keep a gateway connected through WebSocket sync.
2. Confirm requests are forwarded to that upstream.
3. Obtain the upstream row ID from the selector detail and call
authenticated:
```http
DELETE /discovery-upstream/batch
Content-Type: application/json
X-Access-Token: <admin-token>
["<upstream-row-id>"]
```
4. The API returns success and the database row is gone.
5. The delete path emits no DISCOVER_UPSTREAM update/delete; the gateway
retains its previous snapshot and may continue forwarding to the removed
endpoint while it remains healthy.
Use the final upstream in a selector to isolate this missing-notification
bug from the non-empty cache replacement issue in #7791.
### Evidence And Validation Boundary
This finding was independently traced through the controller, service, SQL
mapper, event paths and background reconciliation. No live production delete
was performed for this report.
-
[DiscoveryUpstreamServiceImpl.java:181–184](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/DiscoveryUpstreamServiceImpl.java#L181-L184)
performs only database deletion.
-
[DiscoveryUpstreamController.java:92–94](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-admin/src/main/java/org/apache/shenyu/admin/controller/DiscoveryUpstreamController.java#L92-L94)
exposes that path directly.
- By contrast,
[updateBatch:138–157](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/DiscoveryUpstreamServiceImpl.java#L138-L157)
invokes fetchAll after commit.
- `DiscoveryUpstreamServiceTest.testDelete()` only checks DELETE_SUCCESS
after the mapper call; it does not verify a gateway synchronization event.
- WebsocketDataReconciler's normal loop reconciles PLUGIN, SELECTOR and
RULE, so enabling it does not compensate DISCOVER_UPSTREAM deletion.
### Suggested Fix / Regression Coverage
Collect affected handler IDs before deleting rows, perform the deletion
transactionally, and publish each handler's remaining list after commit. Cover
multiple handler IDs, deleting the final upstream, rollback without
publication, and an integration assertion that a connected gateway stops
selecting the deleted endpoint. Do not rely solely on the SQL row count.
### Environment
Apache ShenYu `2.7.2-SNAPSHOT`, master
`04f7c2e8b7d282f14510157a9ab0bfaab538ecac`; Java 17; MySQL; WebSocket sync.
--
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]
