[imDwAaY]

Fixes #8024
Fixes #8025

Both issues share one root cause: the handler keeps only the newest desired rule (rules), never a record of what it actually registered in the SDK. Every cleanup path therefore has to infer the old state from incoming data, and it gets it wrong after a disable or a rename.

Problem

• [BUG] Disabling an active MCP rule leaves its tool registered and callable #8024 — rule updates arrive through handlerRule, and registerTool returns immediately when enabled=false. A tool registered while the rule was enabled stays in the SDK server and in CACHED_TOOL, and its retained callback keeps invoking the backend.
• [BUG] Renaming an MCP rule tool leaves the previous tool name registered #8025 — addTool only removes an existing tool with the new name. Renaming the tool (via handle.name or a fallback to RuleData.name) or moving its selector leaves the previous name registered next to the new one; a later delete then removes only the current name and orphans the old one.

Fix

The handler now records the identity it applied per rule — ToolRegistration(selectorId, serverPath, toolName) — separately from the desired configuration:

Transition	Behaviour
enabled -> disabled (#8024)	revoke the tracked registration and the cached handle, then keep the disabled snapshot for a later enable
renamed: handle.name or fallback RuleData.name (#8025)	revoke the tracked name before registering the new one
selector moved to another server path (#8025)	revoke on the previous path before registering on the new one
same-name update	identity unchanged, no revocation; addTool replaces the callback as before
duplicate update events	identity unchanged, no repeated removeTool
disable / delete after a rename	the tracked identity decides what to remove, not the incoming payload
rule never registered against a server	falls back to the previous handle-based behaviour
removeSelector	drops the tracked identities of the removed rules

removeRule and the new disable path share unregisterTool, which prefers the tracked identity and falls back to the passed rule data.

Tests

Seven regression tests added to McpServerPluginDataHandlerTest:

• disablingAnActiveRuleRevokesTheRegisteredTool, reEnablingARuleRegistersTheToolExactlyOnce, disablingARenamedRuleRevokesTheRenamedTool ([BUG] Disabling an active MCP rule leaves its tool registered and callable #8024)
• renamingACustomToolNameReplacesTheRegistration, renamingThroughTheRuleNameReplacesTheRegistration, sameNameUpdateReplacesWithoutRevocation, movingASelectorRevokesTheToolFromThePreviousServer ([BUG] Renaming an MCP rule tool leaves the previous tool name registered #8025)

All the transition tests fail against the previous implementation; sameNameUpdateReplacesWithoutRevocation is the guard that keeps the unchanged path unchanged.

./mvnw -pl shenyu-plugin/shenyu-plugin-mcp-server test   # 154 tests, 0 failures (JDK 17)
./mvnw -pl shenyu-plugin/shenyu-plugin-mcp-server checkstyle:check

[Aias00]

Tracking the applied identity separately from the newest desired rule is the right decomposition — it is what makes rename, move and disable all revocable from one place instead of three ad-hoc recomputations of the tool name.

I checked the parts that are easy to get wrong:

• The enabled → disabled transition is caught via previous before rules.put overwrites it, and isRegistered(previous) makes repeated disabled updates a no-op, so removeTool cannot fire twice. The reEnablingARuleRegistersTheToolExactlyOnce test pins exactly that.
• Dropping the registrations entry in removeSelector without calling removeTool is safe: the method ends with shenyuMcpServerManager.removeMcpServer(path), which takes the tools with the server. Worth a one-line comment next to registrations.remove(...), because the invariant lives 9 lines below and is not obvious at that point.
• removeRule now delegates to unregisterTool, which prefers the tracked identity and only falls back to the handle-derived name — that is the right precedence, since a renamed rule no longer matches what the incoming handle describes.

Minor: ToolRegistration's private getters are redundant — a nested class's private fields are already reachable from the enclosing class, so the getters only add noise.

Approving.