Do we have a test for this case? If youPipeReader.CopyToAsync(PipeWriter) and that pipe writer is complete before writing all of the data, and you copy the PipeReader to another Pipewriter and it resumes where it left off and continues copying.

I have added a test proposal. Comments are welcome.
I have checked that without the fix this test case hangs... as expected.
However, I have a doubt around the update of theconsumed position when the flush result is "completed". Indeed, by design, flush comes after write so data is considered as consumed (if not failed), but thePipe.WriteAsync method can return a completed FlushResult before consuming the provided data...
Do I miss something here?

That's a really good point. Lets file another issue. There's basically no way to know if the data has been consumed or not. Great find!

You shouldn't have this check if you're doing other important stuff in this loop (which you are).

This was written during triage when we didn't have the full context yet. I've now read through most of the related issues.

It seems the problem is that when you have a PipeWriter/Reader pair with arbitrary Pause/ResumeThreshold,you cannot observe exactly when the read loop completed just using PipeWriter. This was already the case though. Checking FlushResult.IsCompleted doesn't change that. If anything, it helps you observe the read loop completed earlier than before.

You used by be able to usePipeWriter.OnReaderCompleted and a TCS for this, but that's been obsoleted. If we decide an API for this is important again, we'll want to directly expose aReaderCompletionTask or something like that anyway.

Edit: I see the issue is knowing where the read loop completed, not when. Does this matter? What scenario does PipeReader.CopyToAsync() complete successfully and the app tries to copy from the same, non-reset PipeReader again?

I think we leave this as it was the existing behavior. Assuming it was consumed.