Support streaming calls in the SubchannelCallTracker

[Khazuar]

What version of gRPC and what language are you using?

Grpc.AspNetCore v2.53.0 in C#

What operating system (Linux, Windows,...) and version?

Mac OSX Ventura

What runtime / compiler are you using (e.g. .NET Core SDK version dotnet --info)

.NET 7.0.200

What did you do?

I wrote a custom load balancer for client side load balancing. I used the ISubchannelCallTracker interface to detect when calls happen and complete on a subchannel to know what load they are bearing. This works fine for non-streaming grpc-calls, but it breaks down for streaming-calls.

What did you expect to see?

That the Complete-function of the ISubchannelCallTracker is called once the AsyncServerStreamingCall is disposed in the user-code.

What did you see instead?

The Complete-function is called right after the grpc-call is made, before even the first item is retriebed from the ResponseStream via MoveNext.

Thoughts

I saw this comment in the source and wondered what it would take to handle this case correctly. AsyncServerStreamingCall does have a disposeAction already, but its not clear how it relates to the HttpResponseMessage in the other place and what else needs to be thought of. I would be happy to provide a PR if I could get some pointers.

[JamesNK]

You're right that the current behavior today isn't great for streaming. It should be improved.

I don't know the right way to implement this. I need to research. Because this layer works on HTTP requests, I don't think it knows about gRPC objects and events.

When I wrote this code, I imagined that it would require wrapping the response HttpContent and listening for a dispose or read end event.

@karelz Could you recommend someone who would know the best way to listen for the end of the overall request, i.e. HTTP response stream end. Do you know of other libraries doing something like this with HttpClient today?

[MihaZupan]

the best way to listen for the end of the overall request, i.e. HTTP response stream end

There's no "nice" way to do that currently.

I think your options are either:

1. Create and return your own HttpResponseMessage type where you copy over all the properties and hook into the dispose pattern
2. Replace the Content property with your own that returns a custom stream that tracks EOF/dispose.

Both have a cost (e.g. reallocating the header collection). If these are long-lived responses, option 1 is likely cheaper.

Depending on what's more appropriate for your scenario, note that stream disposal/EOF may happen earlier than response disposal.

---

I don't know of good examples of libraries doing this, HttpClient itself does it internally but we have full control over the content objects.

[Khazuar]

@JamesNK I'd appreciate if a quick solution for this were to be found. The library is just behaving incorrectly at the moment, and there don't seem to be many users of the feature-combination "custom loadbalancer that tracks calls" + "streaming calls", or this bug would have been found earlier. Therefore, a few allocations more will not impact many people. IMHO solving this "properly" via changes to dotnet/runtime might be a performance-improvement to be done later on.

[JamesNK]

Thank you for creating a PR.

I need to test this thoroughly and write unit tests. I'm sure it works for calls that successfully read to the end of the request. This is what you probably tested. But I want to verify calls are correctly ended for failure conditions. Does it still work if the gRPC call ends because of cancellation? Or deadline. Or server abort. Or someone doesn't read from the stream, and it times out. And so on.

[JamesNK]

I don't believe this is possible without changes to HttpClient.