LogoLogo
  • README
  • VERSION 9
    • Version Begins
  • Overview
    • Show me the code!
    • Basic Concepts
    • Why Brighter?
  • Brighter Configuration
    • Basic Configuration
    • How Configuring the Command Processor Works
    • How Configuring a Dispatcher for an External Bus Works
    • RabbitMQ Configuration
    • AWS SNS Configuration
    • Kafka Configuration
    • Azure Service Bus Configuration
    • Azure Archive Provider Configuration
  • Darker Configuration
    • Basic Configuration
  • Brighter Request Handlers and Middleware Pipelines
    • Building an Async Pipeline of Request Handlers
    • Basic Configuration
    • How to Implement an Async Request Handler
    • Requests, Commands and an Events
    • Dispatching Requests
    • Dispatching An Async Request
    • Returning results from a Handler
    • Using an External Bus
    • Message Mappers
    • Routing
    • Building a Pipeline of Request Handlers
    • Passing information between Handlers in the Pipeline
    • Failure and Dead Letter Queues
    • Supporting Retry and Circuit Breaker
    • Failure and Fallback
    • Feature Switches
  • Guaranteed At Least Once
    • Outbox Support
    • Inbox Support
    • EFCore Outbox
    • Dapper Outbox
    • Dynamo Outbox
    • MSSQL Inbox
    • MySQL Inbox
    • Postgres Inbox
    • Sqlite Inbox
    • Dynamo Inbox
  • Darker Query Handlers and Middleware Pipelines
    • How to Implement a Query Handler
  • Health Checks and Observability
    • Logging
    • Monitoring
    • Health Checks
    • Telemetry
  • Command, Processors and Dispatchers
    • Command, Processor and Dispatcher Patterns
  • Under the Hood
    • How The Command Processor Works
    • How Service Activator Works
  • Event Driven Architectures
    • Microservices
    • Event Driven Collaboration
    • Event Carried State Transfer
    • Outbox Pattern
  • Task Queues
    • Using a Task Queue
  • FAQ
    • FAQ
  • END OF VERSION
    • Version Ends
  • VERSION 10
    • Version Begins
  • Overview
    • Show me the code!
    • Basic Concepts
    • Why Brighter?
  • Brighter Configuration
    • Basic Configuration
    • How Configuring the Command Processor Works
    • How Configuring a Dispatcher for an External Bus Works
    • RabbitMQ Configuration
    • AWS SNS Configuration
    • Kafka Configuration
    • Azure Service Bus Configuration
    • Azure Archive Provider Configuration
  • Darker Configuration
    • Basic Configuration
  • Brighter Request Handlers and Middleware Pipelines
    • Building an Async Pipeline of Request Handlers
    • Basic Configuration
    • How to Implement an Async Request Handler
    • Requests, Commands and an Events
    • Dispatching Requests
    • Dispatching An Async Request
    • Returning results from a Handler
    • Using an External Bus
    • Message Mappers
    • Routing
    • Building a Pipeline of Request Handlers
    • Passing information between Handlers in the Pipeline
    • Failure and Dead Letter Queues
    • Supporting Retry and Circuit Breaker
    • Failure and Fallback
    • Feature Switches
  • Guaranteed At Least Once
    • Outbox Support
    • Inbox Support
    • EFCore Outbox
    • Dapper Outbox
    • Dynamo Outbox
    • MSSQL Inbox
    • MySQL Inbox
    • Postgres Inbox
    • Sqlite Inbox
    • Dynamo Inbox
  • Darker Query Handlers and Middleware Pipelines
    • How to Implement a Query Handler
  • Health Checks and Observability
    • Logging
    • Monitoring
    • Health Checks
    • Telemetry
  • Command, Processors and Dispatchers
    • Command, Processor and Dispatcher Patterns
  • Under the Hood
    • How The Command Processor Works
    • How Service Activator Works
  • Event Driven Architectures
    • Microservices
    • Event Driven Collaboration
    • Event Carried State Transfer
    • Outbox Pattern
  • Task Queues
    • Using a Task Queue
  • FAQ
    • FAQ
  • END OF VERSION
    • Version Ends
Powered by GitBook
On this page
  • Retry (and Circuit Break) the Request on the Internal Bus
  • Retry (with Delay) the Request on the External Bus
  • Terminate processing of that Request
  • Run a Fallback
  • Use Custom Middleware

Was this helpful?

Edit on GitHub
  1. Brighter Request Handlers and Middleware Pipelines

Failure and Dead Letter Queues

PreviousPassing information between Handlers in the PipelineNextSupporting Retry and Circuit Breaker

Last updated 2 years ago

Was this helpful?

When a Request is passed to RequestHandler.Handle() it runs in your application code. If your application code fails, you have a number of options:

Any unhandled exception that leaves the Request Handling Pipeline (in other words is not intercepted by middleware) will .

Retry (and Circuit Break) the Request on the Internal Bus

You can use Brighter's support for Polly policies to retry the operation on the Internal Bus. See

A circuit breaker is triggered when all Retry attempts fail, and will prevent further requests from succeeding.

Both the triggering of the circuit breaker, and requests passed to the Request Handler Pipeline while the circuit breaker is open will

Retry (with Delay) the Request on the External Bus

If you the failure is potentially retriable, but you want to retry on the External Bus (by making the message available to be consume from the External Bus again) then you can throw a DeferMessageAction exception. Upon receipt of a DeferMessageAction the pump will Reject the message and Requeue it. with a delay. The delay is configured by the External Bus Subscription.RequeueDelayInMilliseconds property.

You can configure a limit on the number of requeue attempts by setting the Subscription.RequeueCount. A value of -1 will allow infinite retries.

Terminate processing of that Request

An unhandled exception leaving the pipeline results in us terminating processing of the Request.

  • On an Internal Bus that exception will bubble out to the caller.

  • On an External Bus we will nack (or reject) the message. On a queue this will delete the message for all consumers, on a stream we will increment the offset past that message for a consumer group.

We do this because you have responsibility to handle exceptions thrown in your code, not the framework and we assume that non-recovered errors are not potentially retriable.

On and Exernal Bus if your middleware supports a Dead Letter Queue (DLQ), and it is configured in your subscription, when we reject a message it will be copied to the DLQ.

On an External Bus, to prevent discarding too many messages, you can set an Subscription.UnacceptableMessageLimit. If the number of messages terminated due to unhandled exceptions equals or exceeds this limit, the message pump processing the External Bus will terminate.

Run a Fallback

Use Custom Middleware

If you want to take action before exiting a handler, due to a failure you can use a Fallback policy. See for more details

If none of the above options meet your needs, you can define custom approaches to exception handling by building your own middleware, see .

Fallback Policy
Pipeline
Retry and Circuit Breaker
Retry (and Circuit Break) the Request on the Internal Bus
Retry (with Delay) the Request on the External Bus
Terminate processing of that Request
Run a Fallback
Use Custom Middleware
Terminate Processing of the Request
Terminate processing of that Request