anchor.diff:  This is because there is no way for the binder to infer the names of all the DLQ topics the implementation might send to.
   Therefore, if you provide DLQ names using this strategy, it is the application's responsibility to ensure that those topics are created beforehand.
   
  -If `DlqDestinationResolver` is present in the application as a bean, that takes higher prcedence.
  +If `DlqDestinationResolver` is present in the application as a bean, that takes higher precedence.
   If you do not want to follow this approach and rather provide a static DLQ name using configuration, you can set the following property.
   
   [source]
  
positive.code: deserializationExceptionHandler::
  Deserialization error handler type.
  This handler is applied per consumer binding as opposed to the binder level property described before.
  Possible values are - `logAndContinue`, `logAndFail` or `sendToDlq`
  +
  Default: `logAndFail`
  
  
negative.code: Deserialization error handler type.
  This handler is applied at the binder level and thus applied against all input binding in the application.
  There is a way to control it in a more fine-grained way at the consumer binding level.
  Possible values are - `logAndContinue`, `logAndFail`, `skipAndContinue` or `sendToDlq`
  +
  Default: `logAndFail`
  
  