Aias00 opened a new issue, #8025:
URL: https://github.com/apache/shenyu/issues/8025

   ### Is there an existing issue for this?
   
   - [x] I have searched the existing issues.
   
   ### Current Behavior
   
   An MCP rule can define its effective tool name in handle.name, falling back 
to RuleData.name. On update, handlerRule overwrites rules[id] with the new 
snapshot before registering the new name. ShenyuMcpServerManager.addTool only 
removes an existing tool with that new name. The old name remains registered 
with its old callback/request configuration. Later removeRule parses only the 
current handle/name, so deletion can leave the orphaned old tool behind.
   
   ### Expected Behavior
   
   A rule has one current registration identity. When its effective name or 
server binding changes, remove the previous registration before replacing it, 
and ensure subsequent disable/delete removes all registrations owned by that 
rule. Normal same-name updates should continue replacing the callback.
   
   ### Steps To Reproduce
   
   1. Register an enabled rule R with handle.name=old-tool and verify it is 
listed.
   2. Update the same rule ID with handle.name=new-tool, leaving the server 
unchanged.
   3. The handler adds new-tool without calling removeTool for old-tool; both 
names can remain registered.
   4. Delete R. Current removeRule removes new-tool, leaving old-tool orphaned.
   5. Also cover fallback names: blank handle.name with a change to 
RuleData.name.
   
   ### 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
   
   - [Old snapshot overwritten before effective-name 
registration](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-L208)
   - [addTool removes only the incoming 
name](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-plugin/shenyu-plugin-mcp-server/src/main/java/org/apache/shenyu/plugin/mcp/server/manager/ShenyuMcpServerManager.java#L370-L400)
   - [UPDATE sync carries current rule 
data](https://github.com/apache/shenyu/blob/34f2ed036747936a5e28aea2c94cd9b3cddcce47/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/publish/RuleEventPublisher.java)
   
   ### Suggested fix direction
   
   Track the applied registration identity (rule ID, effective server path and 
effective name) separately from the newest desired definition. Revoke the old 
identity on rename/move, then register the replacement with defined failure 
recovery. Do not infer old identity from the incoming payload after overwriting 
it.
   
   ### Acceptance criteria
   
   - Custom-name rename and fallback rule-name rename leave only the current 
name in the actual SDK server.
   - Old names cannot be newly invoked; deleting/disabling the renamed rule 
leaves no orphan.
   - Cover same-name updates, duplicate events and selector/server moves 
without removing unrelated tools.
   - Registration/removal failures leave observable recoverable state.
   
   ### Related work and scope
   
   Related to closed #6473, which corrected choosing the custom name during 
deletion. This report concerns the distinct old-name -> new-name update 
transition; current deletion of the new name does not clean the old 
registration. Suggested priority: P2.
   


-- 
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]

Reply via email to