shreemaan-abhishek opened a new pull request, #13550:
URL: https://github.com/apache/apisix/pull/13550

   ### Description
   
   The `mcp-bridge` message endpoint (`POST <base_uri>/message?sessionId=<id>`) 
trusted the supplied `sessionId` unconditionally: it constructed a server for 
whatever value was passed and pushed the body into that session's shared-dict 
queue, returning `202`. This happened even when no SSE session was ever 
established for that id (including a missing `sessionId`), leaving orphaned 
entries in the `mcp-session` shared dict that nothing drains. This also removes 
the long-standing `TODO: check ctx.var.arg_sessionId` in the access path.
   
   This PR makes the message endpoint only accept messages for a session that 
is actually established:
   
   - When an SSE session is established, it is recorded with a liveness marker 
in the `mcp-session` shared dict. The marker is refreshed by the existing 
keepalive loop and self-expires (TTL) if the worker holding the session goes 
away without running teardown; it is cleared on normal teardown.
   - The message endpoint looks up that marker and returns `404` when the 
`sessionId` is missing or does not correspond to a live session, instead of 
creating a new queue.
   
   #### Which issue(s) this PR fixes:
   
   Fixes #
   
   ### Checklist
   
   - [x] I have explained the need for this PR and the problem it solves
   - [x] I have explained the changes or the new features added to this PR
   - [x] I have added tests corresponding to this change
   - [ ] I have updated the documentation to reflect this change
   - [x] I have verified that this change is backward compatible (If not, 
please discuss on the [APISIX mailing 
list](https://github.com/apache/apisix/tree/master#community) first)
   


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