如何将 ActionBlock 的所有异常包装在单个 AggregateException 中

Question

I came across TPL ActionBlock which seems to be pretty handy for (throttled) parallel async operations. So far I am using Task.WhenAll() (+ Semaphore for throttling). When it comes to exceptions there seem to be big differences though:

var successList = new List<int>();
var failedList = new List<int>();
try
{
    var actionBlock = new ActionBlock<int>(
        async x => await Task.Run(() =>
        {
            if (x < 5)
            {
                failedList.Add(x);
                throw new Exception(x.ToString());
            }

            successList.Add(x);
        }),
        new ExecutionDataflowBlockOptions());

    Enumerable.Range(1, 10).Each(x => actionBlock.Post(x));
    actionBlock.Complete();

    await actionBlock.Completion.ConfigureAwait(false);
}
catch (Exception ex)
{
    // works for approach using task.whenall
    Console.WriteLine(ex);
    Assert.True(failedList.Count == 4);
    Assert.True(successList.Count == 6);
    return;
}

Assert.Fail();

This test fails because ActionBlock stops immediately when exceptions occur. I found this being an issue on github: Dataflow: Add options for Task Faulting . Apparently this behavior is not configurable.

Task.WhenAll() in combination with an extension method like this:

public static async Task PreserveAllExceptions(this Task task)
{
    try
    {
        await task.ConfigureAwait(false);
    }
    catch
    {
        throw task.Exception;
    }
}

Wraps all(!) exceptions in an AggregateException but continues processing:

  await Task.WhenAll(task1,task2).PreserveAllExceptions().ConfigureAwait(false);

Is there a handy way to achieve this using ActionBlock ?

UPDATE : To clarify:

1. I am not planning to use sempahore for throtteling (Why would I?) since there is already such an option in ExecutionDataflowBlockOptions
2. Code snippet is just a dummy to demonstrate the "problem"; Task.Run() is only used as placeholder for an actual async functon.
3. What I really want to do is the following: Process all messages in a parallel fashion. Do not cancel further message processing on error. After processing all messages, return and indicate that at least on error occured and return all errors -> Exactly how my Task.WhenAll() with AggregateException is working. I know I simply could try{}catch{} within my ActionBlock and somehow store the exceptions but I was wondering if there would be any configuration possiblity to make this easier. Anyhow, it's not that big of a deal to just use a try catch and collect exceptions everywhere where I make use of ActionBlock . I just find that the Task.WhenAll() + PreserveException Extension is cleaner for my purpose.

Answer 1

It's unclear what the question asks. What's clear though is that the ActionBlock is misused. There's no need for Task.Run since the ActionBlock already uses one or more worker tasks. There's no need for semaphores, since ActionBlock (and the other blocks) already supports throttling by limiting the number of worker tasks and the input queues.

The code seems to be trying to use exceptions as a control flow mechanism too, which would be wrong in procedural code too.

Exceptions aren't meant to escape the block. Dataflow is a completely different computing paradigm from the common procedural paradigm - there are no functions calling each other, so there's no caller to receive and handle the exception.

In a dataflow, blocks pass messages to each other, in a single direction. Blocks are combined in pipelines or networks, receiving messages, processing them and passing them to any connected blocks. If an exception occurs there's no "caller" that could receive that exception. Unhandled exceptions are catastrophic and bring down the entire pipeline - not just a single block, but any downstream block it's linked to with PropagateCompletion set to true. Upstream block will never know about this though, leading to unexpected situations.

Throttling

Throttling with an ActionBlock is easy - for starters, all blocks use just a single worker task. One can throttle upstream callers by limiting their input buffer and using await block.SendAsync() instead of block.Post . There's no need for Task.Run as the block already uses worker tasks :

var options=new ExecutionDataflowBlockOptions 
{ 
    MaxDegreeOfParallelism=2, 
    BoundedCapacity=2
};
var block =new ActionBlock<Message>(processMessage,options);

...
async Task processMessage(Message msg) { ...}

That's enough to allow only two concurrent operations, and stop posters if there are two messages waiting already. If the buffer is at capacity, SendAsync in the following code will wait until a slot becomes available:

foreach(var msg in someInputCollection)
{
    await block.SendAsync(msg);
}

That's it. The block will process 2 messages concurrently (the default is just 1) and accept only 2 messages at a time in its input buffer. If the buffer is at capacity, the posting loop will wait.

Quick & dirty rate limiting can be achieved by adding a delay in the processing method :

var block =new ActionBlock<Message>(msg=>{
    await Task.Delay(200);
    await processMessage(msg);
},options);

Conditional routing

The question's code seems to be using exceptions to implement control flow. That would be wrong in any library or paradigm. Since dataflows work in networks the equivalent of control flow is conditional routing.

This is also available, through the LinkTo overloads that accept a predicate parameter that decides whether a message should be passed down a specific link.

In the question's case, assuming there's an upstream TransformBlock that produces integers, LinkTo can be used to route messages to different BufferBlocks:

var success=new BufferBlock<int>();
var failure=new BufferBlock<int>();

var block=new TransformBlock<Message,int>(...);
//Success if x>=5
block.LinkTo(success,x=>x>=5);
//By default, everything else goes to Failure
block.LinkTo(failure);

That's it. The only "trick" is that the predicates should cover all options, otherwise messages will remain stuck in block 's output buffer. It helps to use a default link after all others to ensure no messages are left unhandled.

Error Handling

Blocks shouldn't allow exceptions to escape. There are several error handling strategies that depend on what the application wants to do.

Handle and log

One option is to handle them and log them in place, the same way one would handle errors in a web application:

var block =new ActionBlock(msg=>{ try { await processMessage(msg); } catch(Exception exc) { _logger.LogError(exc,....); } },options);

Post to another block

Another possibility is to post the exception, and possibly information about the incoming message, to another block directly. That block could log the error and messag or retry it after a delay. There may be a different pipeline behind that block to retry messages with increasing delays before sending them to a dead-letter buffer, similar to what one would do with message queues:

var block =new ActionBlock<Message>(msg=>{
    try
    {
        await processMessage(msg);
    }
    catch(SomeRetriableException exc)
    {
        _retryBlock.Post(new RetryMsg(msg,exc));
    }
    catch(Exception exc)
    {
       
       _logger.LogError(exc,....);
    }
},options);

The strategy to use depends on what the application does. If the ActionBlock is used as a simple background worker, it may be enough to just log.

Wrap and route

In a more advanced scenario messages can be wrapped in an Envelope<> that carries the message and possibly any exceptions. Routing can be used to separate success from failure messages :

class Envelope<T>
{
    public T Message{get;}
    public Exception Error {get;}
    
    public Envelope (T msg)
    {
        Message=msg;
    }
    
    public Envelope(T msg,Exception err)
    {
        Message=msg;
        Error=err;
    }
}

The block now returns an Envelope :

var block=new TransformBlock<Envelope<Message>,Envelope<int>>(env=>{
    try
    {
        var msg=env.Message;
        ....
        return new Envelope(6);
    }
    catch(Exception exc)
    {
        return new Envelope(msg,exc);
    }
});

This allows routing errors to an errorBlock using conditional routing :

var errorBlock = ActionBlock<Envelope<Message>>(...);

var success=new BufferBlock<int>();
var failure=new BufferBlock<int>();

//Send errors to `errorBlock`
block.LinkTo(errorBlock,env=>env.Error!=null);

//Success if x>=5
block.LinkTo(success,x=>x.Message>=5);
//By default, everything else goes to Failure
block.LinkTo(failure);

Answer 2

There is no easy way to aggregate all exceptions and propagate them through the Completion property of the ActionBlock . Unfortunately the TPL Dataflow components are not easily extensible. You could do it if you really wanted to, by encapsulating an ActionBlock inside a custom block and customizing the Completion of this block. For example:

public class MyActionBlock<TInput> : ITargetBlock<TInput>
{
    private readonly ActionBlock<TInput> _actionBlock;
    private readonly ConcurrentQueue<Exception> _exceptions;

    //...

    public Task Completion
    {
        get
        {
            return _actionBlock.Completion.ContinueWith(t =>
            {
                if (_exceptions.Count > 0)
                    throw new AggregateException(_exceptions);
            });
        }
    }
}

...but this simple code will not propagate cancellation, neither will propagate any exceptions passed through the Fault method of the IDataflowBlock interface. So you'll have to spend considerable amount of effort in order to make it work correctly in all cases, and it's doubtful that the investment will pay of.