fix(connection): preserve notification response ordering - #129

Taking this opportunity, I reread the implementation of connection & transport. It has existed since the initial version and was actually translated from TypeScript. I feel it's a bit too complicated. I'm currently discussing with my agent whether it can be simplified, and there should be a refactoring later.

Please see #132 and check if the issue still exists or you need to update the PR. @hallerite

hey @frostming,
rebased my PR onto main. The issue unfortunately still exists.

This solution has a problem: you are associating all notifications received after a request is sent with that request. In reality, this is not the case. For example, the session/update notification is only relevant when the session id is the same.

However, to achieve this kind of precise association, the Connection—as a low-level communication abstraction—would need to know too much, which violates the principles of software design.

I feel this is still better suited for the Agent/Client to implement and ensure that, and what we need to provide is a way to tell the caller that the notification has been processed, rather than being completely asynchronous.

What do you think?

makes a lot of sense. I have refactored it following your recommendations and it's now also closer to the typescript implementation

both suggestions make sense to me.

regarding the second, I made two small adaptations:

• The currently executing update is excluded from waits initiated inside that update’s handler. Otherwise, if a session_update handler starts a nested prompt for the same session, that prompt would wait for its surrounding update handler, causing a deadlock.
• The wrapped session_update handler is resolved through the existing compatibility mechanism instead of calling client.session_update directly, preserving support for legacy camelCase clients.