CODEWITHSUNDEEP
c#azureservicebus
Yuriy Gavrishov
Yuriy Gavrishov

Reputation: 5021

How to use ServiceBusProcessor.ProcessErrorAsync

ServiceBusProcessor cannot be used without specifying ProcessMessageAsync and ProcessErrorAsync. What is the first method, it's very clear but I'm not sure what to do in ProcessErrorAsync? Are the following methods identical?

var client = new ServiceBusClient(connectionString);
var processor = _client.CreateProcessor(queueName);

processor.ProcessMessageAsync += async arg =>
{
    try
    {
        //process message
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
};

processor.ProcessErrorAsync += arg =>
{
    return Task.CompletedTask;
};

await _processor.StartProcessingAsync(cancellationToken);

and

var client = new ServiceBusClient(connectionString);
var processor = _client.CreateProcessor(queueName);

processor.ProcessMessageAsync += async arg =>
{
    //process message
};

processor.ProcessErrorAsync += arg =>
{
    Console.WriteLine(ex.Message);
    return Task.CompletedTask;
};

await _processor.StartProcessingAsync(cancellationToken);

Upvotes: 6

Views: 3128

Answers (1)

Jesse Squire
Jesse Squire

Reputation: 7745

ProcessMessageAsync is a handler that will be called each time a message is read from your Service Bus instance and needs to be processed. This is where your business logic for handling messages should be.

ProcessErrorAsync is a handler that allows you to observe exceptions that occur during processor operation - both in your message processing code and within the processor infrastructure itself.

The processor is built to be resilient and do it's best to recover from problems and continue processing. Because of this, it will shrug off most exceptions, surface them to the handler, and then continue moving forward. The error handler is how your application is notified of problems and take the actions appropriate for your application.

As for what you should do in the handler, much of that depends on your application and its needs. At minimum, most applications want to understand when errors occur and log them in case analysis is needed at a later point. You may also want to use this to detect poison messages or other processing problems and takes the action that is appropriate for your application.

The processor has no knowledge of your application's design or needs, nor that of the the environment in which it is hosted. That means that it cannot make intelligent decisions about when a normally transient issue should be fatal or when there's a bigger issue in your application ecosystem. It is important to remember is your application is responsible for understanding the pattern of errors and determining if the application or processor is not healthy in a non-obvious way.

For example, if the processor cannot reach your Service Bus instance, it will continue to retry forever. If your application sees these exceptions consistently for a period of time, it may be a sign of an unhealthy host network and your application may choose to stop processing and reset the host. Likewise, if your application is expecting a specific schema for incoming messages and those published to your Service Bus instance aren't correct, the processor will continue to try handling them, but your application should be better able to recognize the larger problem and take the appropriate action.

Upvotes: 6

Related Questions