You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 8, 2024. It is now read-only.
I have a streaming call that is being processed by a client that I want to interrupt partway through. What is the correct way to do this such that the server is notified as well?
For example, when I am processing the stream, I use StreamExt::take_until to stop it partway if a certain condition is satisfied. I then call the same streaming endpoint/function again. On testing, I have found that the server now sees two streams still "up". The stream from the server side is perpetual in this case.
I have found that the only way to actually shut down the call is to call shutdown_background() on the tokio runtime used to create the client after dropping the client object. Otherwise the server keeps sending data on the "dropped" streaming call. It never detects a disconnect unless I shutdown the tokio runtime. I am testing against a Python test server right now.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
My question is similar to these:
grpc/grpc#8023
grpc/grpc-java#3095
I have a streaming call that is being processed by a client that I want to interrupt partway through. What is the correct way to do this such that the server is notified as well?
For example, when I am processing the stream, I use StreamExt::take_until to stop it partway if a certain condition is satisfied. I then call the same streaming endpoint/function again. On testing, I have found that the server now sees two streams still "up". The stream from the server side is perpetual in this case.
I found a further post about this: https://users.rust-lang.org/t/futures-streams-grpc-rs-how-to-cancel-a-server-to-client-stream/26858
I am seeing a similar behavior. Even if I forcibly drop the client, the server keeps sending messages until the client program exits.
The text was updated successfully, but these errors were encountered: