test: reproduce websocket client echo bug#6
Closed
kamikaz1k wants to merge 1 commit into
Closed
Conversation
3 tasks
markpollack
pushed a commit
that referenced
this pull request
May 26, 2026
AcpClientSession wired the transport with doOnNext(this::handle), which performs the side effect but passes the original message through downstream. The WebSocket transport then sent it back over the wire, causing the agent to receive its own requests as inbound client messages. Fix: consume the message after handling with .then(Mono.empty()) so nothing passes through to the transport's outbound path. Test reproduction by Kaiser Dandangi (@kamikaz1k) via PR #6.
Contributor
|
Good catch. The root cause analysis is correct — Applied your test and the fix ( Thanks for the clean reproduction — the test isolates the bug path well. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a reproduction of an issue I found while working on the HTTP SSE Client. I can do the follow up work to fix this, but wanted to make sure I understood the intention behind this as I expect there are in the wild consumers of this SDK and might be affected by any changes.
This behaviour seems to be Java SDK implementation specific.
The issue is: client handles request correctly AND accidentally emits the original request back through the transport handler.
The root cause is:
doOnNext(...)performs a side effect, but it does not replace the message. It passes the original inbound request downstream unchanged.and so the fix would be to