ASP.NET Core middleware with unbounded output - asp.net-core

Question

I have a piece of ASP.NET Core middleware that produces an unbounded amount of data when it takes over processing a request. It goes into a loop that calls await context.Response.Body.WriteAsync as long as it is allowed to. If the caller stays connected, it expects to keep receiving data. This service is being hosted with Kestrel, and it seems to be working properly as described so far. But, what I am finding is that when the caller disconnects, Kestrel doesn't seem to notice and continues pumping output from the middleware. That output isn't going anywhere, because the memory usage of the process isn't going up, and at the same time netstat -an doesn't show the connection any more. But, the middleware just keeps on chugging away.
For typical HTTP requests, this wouldn't be a terribly serious issue, because most of the time the client doesn't disconnect when it has only read part of the request, and in those cases where it does, the response is finite in size anyway. But the pattern with this endpoint is that the data is conceptually infinite in length, and the caller stays connected for as long as it wants and then signals that it no longer wants further data by disconnecting.
These images illustrate the problem:
https://imgur.com/a/9Qp7VV3
How can I make it so that the middleware notices when the client disconnects?

Answer 1

I also posted this as an issue on the aspnetcore GitHub repo, and I got a reply that explained the problem and provided a solution:
https://github.com/dotnet/aspnetcore/issues/22156
Basically, for better or worse, the ASP.NET Core infrastructure suppresses all errors from write operations, and so if the request has been aborted, calling context.Response.Body.WriteAsync fails silently. I personally think there's a mistake in there somewhere, but the rationale given is that this reduces exception/log spam from behaviours over which the server has no control.
Because of this, if you're writing a loop like mine, you have to explicitly check for the request having been aborted. The context provides a CancellationToken that is used to capture aborts. You can also use this CancellationToken on other actions the handler is doing that aren't within the scope of the request context.
My data pump looks like this now:
while (true)
{
int bytesRead = await responseStream.ReadAsync(buffer, 0, buffer.Length, context.RequestAborted);
if (bytesRead < 0)
throw new Exception("I/O error");
if (bytesRead == 0)
break;
await context.Response.Body.WriteAsync(buffer, 0, bytesRead);
if (context.RequestAborted.IsCancellationRequested)
break;
_statusConsoleSender.NotifyRequestProgress(requestID, bytesRead);
}