Echoing messages back to the client change how embedded channels in them work. #13
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.
I ran into this when I was working on something in Aetherboard,
so I put it together in a simplified test case to help debug/fix the issue.
The first new test, ensures that i can embed a writeable into a message,
and then while piping the channel it is sent on,
I should always be able to pipe the writeable into something.
This is with any of the sessions, or even with just 1 graft instance.
The second test, is where I pass a return channel to the server and expect
it to echo the messages back to me.
I expect to be able to pipe the return channel messages in the same way as the
messages are piped on the remote side, or as they are piped directly from the client.
What happens is that the channel attached to the messages that gets echoed back,
can no longer be piped from.
Echoing messages back is actually one of the more common network behaviours,
such as for instance in group chat. When I post a message, I need to wait for it to be
sent back to me to be added into the single stream of conversation.
any hints where to start looking to fix this @mcollina ?