I am able to publish messages to DLX when they are not able to process due to insufficient information or any other issues with the message received by binding DLX for the queue through Spring AMPQ.
For instance, invoice received with missing of billable hours and/or no employee id present it it.
{
"invoiceId": "INV1234",
"hourRate": 18.5,
"hoursWorked": 0,
"employeeId": "EMP9900"
}
Due to less size of request body, it's easy to understand what is the issue. But, we have some considerable request body length and 15-20 validation points.
Producer of the message expecting what is the issue when pushing back the message to publishing back them through DLX.
I have the following two thoughts to address this requirements.
Option #1: Append the errors information to the original message.
{
"message": {
"invoiceId": "INV1234",
"hourRate": 18.5,
"hoursWorked": 0,
"employeeId": "EMP9900"
},
"errors": [
{
"errorCode": "001",
"errorMessage": "Invalid no. of hours."
},
{
"errorCode": "002",
"errorMessage": "Employee not found in the system."
}
]
}
Option #2 : Add additional errors object in the headers
Out of these two options,
See the documentation. The framework implements your #2 solution.
Starting with version 1.3, a new
RepublishMessageRecoverer
is provided, to allow publishing of failed messages after retries are exhausted.
...
The
RepublishMessageRecoverer
publishes the message with additional information in message headers, such as the exception message, stack trace, original exchange, and routing key. Additional headers can be added by creating a subclass and overriding additionalHeaders().