anchor.diff:  spring.cloud.stream.rabbit.bindings.input.consumer.republish-to-dlq=true
   ----
   
  -Doing so forces the internal error handler to intercept the error message and add additional information to it before publishing it to DLQ. 
  +Doing so forces the internal error handler to intercept the error message and add additional information to it before publishing it to DLQ.
   Once configured, you can see that the error message contains more information relevant to the original error, as follows:
   
   [source,text]
  
positive.code: ----
  spring.cloud.stream.bindings.error.destination=myErrors.
  ----
  
  ===== System Error Handling
  
  
negative.code: }
  ----
  
  In the preceeding example the destination name is `input.myGroup` and the dedicated error channel name is `input.myGroup.errors`.
  
  NOTE: If `group` is not specified anonymous group is used (something like `input.anonymous.2K37rb06Q6m2r51-SPIDDQ`), which is not suitable for error
  handling scenarious, since you don't know what it's going to be until the destination is created.
  
  Also, in the event you are binidng to the existing destination such as:
  
  [source,text]
  ----
  spring.cloud.stream.bindings.input.destination=myFooDestination
  spring.cloud.stream.bindings.input.group=myGroup
  ----
  
  the full destination name is `myFooDestination.myGroup` and then the dedicated error channel name is `myFooDestination.myGroup.errors`.
  
  Back to the example. . .
  
  The `handle(..)` method, which subscribes to the channel named `input`, throws an exception.  Given there is also a subscriber to the error channel `input.myGroup.errors`
  all error messages are handled by this subscriber.
  
  