The right place for this kind of question is the GitHub Issue tracker for CoreWCF, where you'll find several related issues. You're not the first one to hit bugs in streaming mode, which is... fragile. Just turning HTTPS on or off can break it: https://github.com/CoreWCF/CoreWCF/issues/1391
Unbounded streaming is something WCF was not designed to support, and hence CoreWCF doesn't support it either. CancellationTokens, etc... might improve things in case of accidental disconnection of a client session, but in general WCF expects streamed responses to have a finite length and be explicitly terminated with an end-of-stream by the server.
E.g.: read the end of this section: https://learn.microsoft.com/en-us/dotnet/framework/wcf/featu...
"Streamed transfers end and the message is closed when the stream reaches the end of file (EOF). When sending a message (returning a value or invoking an operation), you can pass a FileStream and the WCF infrastructure subsequently pulls all the data from that stream until the stream has been completely read and reached EOF."
Fundamentally, WCF is a message-oriented RPC system. It has many issues with streaming: it has to be explicitly enabled, it is incompatible with many features, etc...
Just "read between the lines" in your stack trace! It mentions XML encoding in several places, but XML as used in RPC uses a "tree" structure which must be terminated with closing tags.
You might be able to shoehorn unbounded streams into CoreWCF by implementing custom channels and encodings, but at that point it isn't really WCF any more!
The bug is that CoreWCF really should give up and stop writing if the client is disconnected. Stepping through its code, it does look like it loses track of the CancellationToken at some point, probably riiiight here: https://github.com/CoreWCF/CoreWCF/blob/067f83b490332120f45e...
Note the comments surrounding it talking about things like "TODO: Verify that the cancellation token is honored for timeout" and "Since HTTP streams don't support timeouts, we can't just use TimeoutStream here." That sounds unfinished to me.
I can't be sure, but there seem to be some design flaws that also contribute to this bug. E.g.: CoreWCF uses synchronous writes to ASP.NET Core's pipeline, which is... also a buggy mess because it is so rarely used.
Then, somehow, it is still writing to a socket that is long gone, which is really odd. It really does feel like there's at least a DoS security bug here, either in ASP.NET when operating in sync mode or in CoreWCF. The issue is that malicious clients could easily request many large responses, disconnect, and the server would keep processing the requests for hours and hours.