My stackoverflow question was closed so here's a blog post about CoreWCF

I didn't, but I've not had much previous success with these kinds of issues.

Just for the sake of it, I've now tried pasting this whole blog into claude.

It has some strange suggestions, including many things that don't work, such as adding to the client:

                // Important: Properly close the stream
                randomStream.Close();

I read the Stream documentation ( https://learn.microsoft.com/en-us/dotnet/api/system.io.strea... ), and it points out:

> This method calls Dispose, specifying true to release all resources. You do not have to specifically call the Close method. Instead, ensure that every Stream object is properly disposed.

My stream is properly disposed.

Claude also sticks in things like:

                // Simulate some work or add a small delay to prevent CPU spinning
                Thread.Sleep(1);

I can't see how that do anything to solve my issue. I suppose I should humour the machine, go full-vibe and try everything it suggests, and if I end up with a working solution go back from there, but I fear that would just leave me more confused about the underlying mechanisms here.

On the client side it not only rewrites my reading to read multiple times, but adds in:

                    await Task.Delay(500, cts.Token); // Small delay between reads

I didn't ask it to re-introduce the loop, and a 500ms delay between reads is horribly long for reading successive bytes from a stream.

The only thing that was interesting was creaitng a linked cancellation token source on the service to pass to the underlying stream and cancelling it on server shutdown.

That's a useful thing to keep in mind to help with helping to shutdown the services, but doesn't actually address the issue for a server you want to keep running.

It does also add send/receive timeouts too, and they're also worth keeping in mind, but that doesn't seem like a good mechanism for dealing with this issue. If anything, it would just mask the issue by having it write to the stream for the duration of the timeout period instead, which if short could cause a problem like this to go unnoticed until it's actually under more load.