Aias00 opened a new issue, #8024: URL: https://github.com/apache/shenyu/issues/8024
### Is there an existing issue for this? - [x] I have searched the existing issues. ### Current Behavior McpServerPluginDataHandler.handlerRule replaces its stored rule snapshot and calls registerTool. If enabled=false, registerTool returns immediately without removing the previously registered tool or its CACHED_TOOL entry. Rule updates are sent as UPDATE events and CommonPluginDataSubscriber calls handlerRule, not removeRule. A tool registered while the rule was enabled therefore remains in the SDK registry after the rule is disabled. The retained callback contains its old request configuration and does not check that originating rule's enabled state. ### Expected Behavior An enabled-to-disabled transition must revoke the old SDK tool registration and active tool cache entry. Existing server sessions should no longer discover or start that tool once the update is applied. Retain enough desired rule state for a later enable to register it exactly once; do not treat disable as permanent rule deletion. ### Steps To Reproduce 1. Create an MCP selector/server and an enabled rule registering tool T with an echo HTTP backend. 2. Confirm tools/list contains T and a baseline tools/call works. 3. Disable the same rule through Admin and wait for the UPDATE to reach the gateway. 4. Inspect the live SDK registry/list and attempt a new call on an established session. Source inspection shows the old registration/callback is not removed. 5. Re-enable the rule and verify exactly one current registration is restored. The existing disabledRulesAreNotReplayedWhenSelectorsArrive test covers initially disabled rules, not an already-active rule becoming disabled. ### Environment - ShenYu master / 2.7.2-SNAPSHOT, commit `34f2ed036747936a5e28aea2c94cd9b3cddcce47`. - Source-inspection report. The reporting environment has no available JDK; no Maven/JUnit, live backend or Redis reproduction is claimed. - Existing runtime behavior; unrelated to proposed plugin orchestration. ### Debug logs No runtime logs captured. Code evidence follows. ### Code evidence - [Snapshot replacement and disabled-rule early return](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-mcp-server/src/main/java/org/apache/shenyu/plugin/mcp/server/handler/McpServerPluginDataHandler.java#L154-L190) - [Rule update publishes UPDATE](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/publish/RuleEventPublisher.java) - [UPDATE invokes handlerRule](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/cache/CommonPluginDataSubscriber.java) - [Callback retains tool definition/request configuration](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-mcp-server/src/main/java/org/apache/shenyu/plugin/mcp/server/callback/ShenyuToolCallback.java) - [Existing initial-disable replay coverage](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-mcp-server/src/test/java/org/apache/shenyu/plugin/mcp/server/handler/McpServerPluginDataHandlerTest.java) ### Suggested fix direction Compare the previous rule/registration with the incoming state before overwriting it. On disable, remove the effective old tool name from its server and invalidate its active cache entry. Separate desired replay state from active registration state, and define failure reporting when SDK removal cannot be applied. ### Acceptance criteria - Transition enabled -> disabled removes the actual SDK tool, not merely a local snapshot. - New calls using the disabled name fail without invoking the backend; tools/list is updated for supported transports/sessions. - Cover initially disabled rules, re-enable, duplicate updates and selector replay. - A failed SDK update is not silently reported as successful revocation. ### Related work and scope This is an active-to-disabled transition defect, distinct from the early-rule replay fix #7942 and custom-name deletion fix #6473. Suggested priority: P1 because an explicit disable does not revoke the exposed operation. -- 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]
