Lack of context.Context support in Send/Receive

[GiedriusS]

Is your feature request related to a problem? Please describe.

I want to implement a fan-out in my service where a request would be sent to multiple nodes and then all of the responses would be streamed back to the client. I want to be able to return partial data if some Receive() has lagged for too much i.e. to not block for the whole duration/context of the stream

Describe the solution you'd like

https://github.com/bufbuild/connect-go/blob/159c8011dfbb90d26b040f8800316e24a6cdb6e3/protocol_grpc.go#L341
https://github.com/bufbuild/connect-go/blob/159c8011dfbb90d26b040f8800316e24a6cdb6e3/protocol_grpc.go#L466

I think these methods should accept context.Context as the first parameter.

Describe alternatives you've considered

The alternative is to spawn another goroutine (for example) just for implementing a timeout. It's wasteful of resources, it forbids receiving messages as fast as possible because you need to have a channel in the middle, and it introduces unnecessary complexity

Additional context

N/A

[akshayjshah]

Hi @GiedriusS - this would be great! Unfortunately, even if Send and Receive accepted a context, there's nothing useful we can do with it. 😿

Under the hood, all of these APIs are wrapping net/http.ResponseWriter.Write and net/http.Request.Body.Read. Neither of those methods takes a context or any other way to set a timeout. Especially since HTTP/2 supports multiple concurrent streams on each connection, there's not even much we can do with the net.Conn APIs. This is tracked and discussed pretty thoroughly in golang/go#16100, and it's also mentioned briefly in the Connect docs on deployment.

Clients take a context.Context for each RPC and set deadlines appropriately, so you can fan out at an RPC level. For streaming RPCs, the timeout or deadline applies to the whole stream - there's no good way to set a deadline for each Send or Receive.

[f0o]

Sorry to revive this old thread; Do you happen to know if BidiStreamForClient.Send can be called concurrently from multiple goroutines or would I need to wrap it in a mutex to ensure it is only called once at a time?

[jhump]

I know this isn't called out well in the docs, so we need to update doc comments to make it more clear. But there is a subtle mention of this here: https://pkg.go.dev/connectrpc.com/connect#StreamingClientConn

Basically, multiple concurrent calls to Send could be a race condition and should be protected by a mutex. But one goroutine calling Send concurrently with another that calls Receive is safe.

[f0o]

Thanks for the quick answer! Mutexes it is then :)

[GiedriusS]

Thanks for your quick reply! I was not aware of that limitation, thank you for the link. I read through it, it's understandable now. I guess we can close this 😢 or we can keep this open so that it wouldn't be forgotten?

[bufdev]

Moving to a discussion