Is ServerStream.Context() guaranteed to expire when handler returns?

[starius]

I’m trying to determine whether it’s necessary to wrap ServerStream.Context() with context.WithCancel in my handler or if it can be avoided. The context is passed to a long-running function that needs to be canceled as soon as the handler returns to release resources.

I assume that ServerStream.Context() will automatically expire when the handler returns, so it should be safe to pass it directly to the long-running function. However, I couldn’t find any confirmation of this behavior in the documentation or source code.

Could someone clarify whether ServerStream.Context() expires when the handler returns? If so, could you please point me to the relevant documentation or source code reference?

[purnesh42H]

@starius i am assuming you are talking about your service handler? If yes, you likely don't need to wrap ServerStream.Context() with context.WithCancel in most cases because it is already cancellable. The context you get from ServerStream.Context() is tied to the lifecycle of the gRPC stream. It will be automatically cancelled when:

• The client closes the connection.
• The client cancels the RPC.
• The server encounters an error during the stream.
• The RPC reaches its deadline (if one is set).

If you need to cancel the long-running function independently of the gRPC stream's lifecycle (e.g., based on some internal server condition), then context.WithCancel would be appropriate.

The only thing you need to make sure your long-running function respects context cancellation. Check ctx.Done() periodically and gracefully stop processing when the context is cancelled.

Let me know if you have anymore questions

[purnesh42H]

Closing this issue. Feel free to re-open if anymore questions.

[starius]

Hey @purnesh42H,
Sorry for the late reply—I was offline.

Could you clarify what happens if my RPC handler on the server side returns nil? To be clear, I'm referring to a scenario where it's not an error but simply the normal end of a stream. This case doesn't seem to be addressed by any of the situations in the list you shared.

[purnesh42H]

@starius in both cases when the client cancels the rpc or rpc finish successfully, the provided context is canceled. Hence, you don't have to close it manually.

However, as i mentioned in case you are spawning resources that needs to be cleaned up when context get's canceled, you need watch for context.Done() and do the cleanup. For example, in case of deadlines.

You can read more about deadlines on the server and deadline propagation here https://grpc.io/docs/guides/deadlines/#deadlines-on-the-server

https://grpc.io/docs/guides/cancellation/#cancelling-an-rpc-call-on-the-client-side might be a good read to understand what happens when client cancels an RPC.

[starius]

Thanks, @purnesh42H ! I got an answer to my question.