[[rabbit-error-channels]]
= Error Channels

Starting with version 1.3, the binder unconditionally sends exceptions to an error channel for each consumer destination and can also be configured to send async producer send failures to an error channel.
See "`xref:spring-cloud-stream/overview-error-handling.adoc[Error Handling]`" for more information.

RabbitMQ has two types of send failures:

* Returned messages,
* Negatively acknowledged https://www.rabbitmq.com/confirms.html[Publisher Confirms].

The latter is rare.
According to the RabbitMQ documentation "[A nack] will only be delivered if an internal error occurs in the Erlang process responsible for a queue.".
You can also get a negative acknowledgment if you publish to a bounded queue with `reject-publish` queue overflow behavior.

As well as enabling producer error channels (as described in "`xref:spring-cloud-stream/overview-error-handling.adoc[Error Handling]`"), the RabbitMQ binder only sends messages to the channels if the connection factory is appropriately configured, as follows:

* `ccf.setPublisherConfirms(true);`
* `ccf.setPublisherReturns(true);`

When using Spring Boot configuration for the connection factory, set the following properties:

* `spring.rabbitmq.publisher-confirms`
* `spring.rabbitmq.publisher-returns`

The payload of the `ErrorMessage` for a returned message is a `ReturnedAmqpMessageException` with the following properties:

* `failedMessage`: The spring-messaging `Message<?>` that failed to be sent.
* `amqpMessage`: The raw spring-amqp `Message`.
* `replyCode`: An integer value indicating the reason for the failure (for example, 312 - No route).
* `replyText`: A text value indicating the reason for the failure (for example, `NO_ROUTE`).
* `exchange`: The exchange to which the message was published.
* `routingKey`: The routing key used when the message was published.

Also see xref:rabbit/rabbit_overview/publisher-confirms.adoc[Publisher Confirms] for an alternative mechanism to receive returned messages.

For negatively acknowledged confirmations, the payload is a `NackedAmqpMessageException` with the following properties:

* `failedMessage`: The spring-messaging `Message<?>` that failed to be sent.
* `nackReason`: A reason (if available -- you may need to examine the broker logs for more information).

There is no automatic handling of these exceptions (such as sending to a xref:rabbit/rabbit_dlq.adoc[dead-letter queue]).
You can consume these exceptions with your own Spring Integration flow.
