Aias00 opened a new issue, #7773: URL: https://github.com/apache/shenyu/issues/7773
### Current behavior The discovery update path persists `serverList`, `props` and type to the database and returns success without invoking its runtime discovery processor. The existing repository cached by discovery ID continues using its previous configuration. A later `createDiscovery(updatedRecord)` call is not a reconciliation mechanism either: `AbstractDiscoveryProcessor.createDiscovery()` returns immediately when the ID is already present, without comparing configuration or reinitializing the repository. ### Locations / reachable flow - `POST /discovery/insertOrUpdate` delegates to `DiscoveryServiceImpl.createOrUpdate()`; an existing ID selects `update()`. - [DiscoveryServiceImpl.java:261–275](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/DiscoveryServiceImpl.java#L261) writes only the database row. - [AbstractDiscoveryProcessor.java:83–103](https://github.com/apache/shenyu/blob/66d7d954ca37d651a5ad916f988a8081157a7ab4/shenyu-admin/src/main/java/org/apache/shenyu/admin/discovery/AbstractDiscoveryProcessor.java#L83) checks only cached ID existence. - `DiscoveryServiceImpl.syncData()` also calls that ID-cached `createDiscovery()` path, so repeating it does not refresh an existing repository configuration. ### Reproduction / validation A Java probe compiled the current service, service interface, abstract processor and registry factory source. A recording mapper accepted an update to an existing ID while the processor holder recorded calls. A second part seeded the processor's actual repository cache with an existing repository instance, then called its real `createDiscovery()` with the updated record: ```text UPDATE_RESULT_PRESENT=true WRITTEN_SERVER=http://registry-new.invalid:2379 PROCESSOR_CALLS=0 RECREATE_KEEPS_OLD_REPOSITORY=true REPOSITORY_REINIT_CALLS=0 ``` An independent reviewer traced the controller, update and full-sync paths and found no in-use immutability check or replacement call. Mapper and repository I/O were mocked; no real registry/network connection or restart was performed. The observed facts are successful persistence without processor reconciliation and retention of the old cached repository. ### Impact / suggested fix An operator can save new registry endpoints/properties and receive success while discovery continues following the old runtime configuration until repository recreation or restart. Changing discovery type can similarly leave the old processor's resources active. Reconcile a committed configuration change with a safely staged replacement, restore watches, and release old resources only after a successful handoff; alternatively explicitly reject unsupported connection-field changes for an active discovery instead of silently accepting them. ### Related existing work #6827 concerns namespace scoping in discovery UPDATE/DELETE WHERE clauses. #7468 concerns import duplicate keys; #7469 import relation ID remapping; #6479 gateway upstream deletion propagation. None reconciles changed discovery connection configuration with an already live repository. Complete-title/open-PR and targeted discovery/serverList/update searches found no matching report. ### Reviewed revision Apache ShenYu 2.7.2-SNAPSHOT, `master@66d7d954ca37d651a5ad916f988a8081157a7ab4`. P2 / Medium; high confidence. Unit-test and CI issue categories excluded. -- 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]
