ChannelReader.ReadAllAsync(CancellationToken) not actually cancelled mid-iteration

Question

I've been working on a feature that queues time consuming work in a channel, and there I iterate the channel using e.g. await foreach(var item in channel.Reader.ReadAllAsync(cancellationToken)) {...}

I was expecting that when cancellation is requested through that cancellationToken, ReadAllAsync would throw on the first iteration that follows the cancellation.

As it seems to me, that is not the case. The loop continues until all items are processed, and then it throws an OperationCanceledException.

This looks a bit strange, to say the least. From ChannelReader's github repo one could see that the cancellation token is marked with the [EnumeratorCancellation] attribute, and so it should be passed to the state machine generated around yield return item; (please correct me if I'm wrong).

My question is, is this a (somewhat) normal behavior of ReadAllAsync(CancellationToken), or am I missing something?

Here is a simple test code that demonstrates the issue (try it on dotnetfiddle):

var channel = Channel.CreateUnbounded<int>();
for (int i = 1; i <= 10; i++) channel.Writer.TryWrite(i);
int itemsRead = 0;
var cts = new CancellationTokenSource();
try
{
    await foreach (var i in channel.Reader.ReadAllAsync(cts.Token))
    {
        Console.WriteLine($"Read item: {i}. Requested cancellation: " +
            $"{cts.Token.IsCancellationRequested}");

        if (++itemsRead > 4 && !cts.IsCancellationRequested)
        {
            Console.WriteLine("Cancelling...");
            cts.Cancel();
        }
    }
}
catch (OperationCanceledException)
{
    Console.WriteLine($"Operation cancelled. Items read: {itemsRead}");
}

Here is the output from the above. Note how item fetching continues after it should have been cancelled in the middle:

Read item: 1. Requested cancellation: False
Read item: 2. Requested cancellation: False
Read item: 3. Requested cancellation: False
Read item: 4. Requested cancellation: False
Read item: 5. Requested cancellation: False
Cancelling...
Read item: 6. Requested cancellation: True
Read item: 7. Requested cancellation: True
Read item: 8. Requested cancellation: True
Read item: 9. Requested cancellation: True
Read item: 10. Requested cancellation: True
Operation cancelled. Items read: 10

Answer 1

More of an update than actual answer, to whoever has had to research the same matter: this behavior is now specified in the documentation regarding ChannelReader.ReadAllAsync() here

The second sentence describing the cancellation token's effect ("If data is immediately ready for reading, then that data may be yielded even after cancellation has been requested.") has been added as a result of raising this subject.

Thanks to everyone involved!

Answer 2

This behavior is by design. I am copy-pasting Stephen Toub's response from the related GitHub issue:

I would like to ask if this behavior is by design.

It is. There's already data available for reading immediately, so there's effectively nothing to cancel. The implementation of the iterator is just sitting in this tight loop:

while (TryRead(out T? item)) 
{ 
   yield return item; 
} 

as long as data is available immediately. As soon as there isn't, it'll escape out to the outer loop, which will check for cancellation.

That said, it could be changed. I don't have a strong opinion on whether preferring cancellation is preferable; I expect it would depend on the use case.