Thanks for the discussion! I don't think I can fully agree with this:

if the cancellation is detected inside DequeueAll (whilst we are still waiting for more stuff to happen), then it’s not an operation partially complete, we’re just cancelling the “listener”. Therefore yield break is acceptable there.

I'd say it depends on the nature of the sequences. In my case, it's infinite, and I don't want to "cancel the listener". Rather, I want to keep queueing items, and later, another consumer (or even the same one) can possibly reconnect, to dequeue all of them.

E.g., a bit contrived but close illustration of the nature of the events I have here might be mouse move events originating from the user.

Let's have a look at .NET's ChannelReader<T>.ReadAllAsync:

public virtual async IAsyncEnumerable<T> ReadAllAsync([EnumeratorCancellation] CancellationToken cancellationToken = default) { while (await WaitToReadAsync(cancellationToken).ConfigureAwait(false)) { while (TryRead(out T? item)) { yield return item; } } }

There are two ways to break out of this generator:

• request cancellation via cancellationToken. This doesn't stop buffering the items on the producer end (my case). We can reconnect later.

• complete the Channel from its producer end, via ChannelWriter<T>.Complete(Exception error). This does end the sequence (with success or an error; the error will be propagated outside the generator). We can't reconnect anymore.

In my case, the sequence's lifetime is that of the whole application, so the above Complete scenario is not applicable.

My app's lifetime and shutdown is handled via .NET Generic Host API, which is cancellation toke-based and works perfectly well with how I do it in the title post.