Open amenzhinsky opened 1 week ago
There are two improvements we could make here:
Close
method of a server stream (and CloseResponse
method of a bidi stream) are graceful operations. They will not abort the RPC and attempt to consume the remainder of the server's response before returning. They are generally used to release any remaining resources associated with an RPC after the server's response has been fully consumed. If you want to abort the RPC before the server's response has been received, one must cancel the context.Context
that was used to create the RPC. Cancelling an RPC this way will trigger a cancellation error in the server.Close
method to have better time and network I/O bounds. So if it takes longer than N duration or consumes more than X bytes, it would skip the graceful close and cancel the RPC. We'd need to agree on reasonable values of N and X and also decide whether to expose client options to customize these values.@jhump Hello, thank you for the fast answer! Can it be implemented by creating a new context with cancel inside rpc method call and cancel it on stream.Close?
Can it be implemented by creating a new context with cancel inside rpc method call and cancel it on stream.Close?
Yes.
Can it be implemented by creating a new context with cancel inside rpc method call and cancel it on stream.Close?
Yes.
To be sure, I told about implementing that on connect lib side, and you?
It is the same either way. But in the connect lib side:
Describe the bug
A client service needs to forcibly stop a server stream, but the Close method hangs indefinitely, preventing the connection-handling function from ever returning.
To Reproduce
And in
example_test.go
:Environment (please complete the following information):
connect-go
version or commit: v1.16.2go version
: go1.22.4go.mod
: