...

• Adding the errors.deadletterqueue.topic.name configuration. This configuration is only modifying the behavior of the out of the box exceptions handlers and would have no effect if a custom exception handlers is implemented, for example:
  • if errors.deadletterqueue.topic.name=null (default), then no records are sent to any dead letter queue
  • if errors.deadletterqueue.topic.name is set, exceptions happening during processing, production or deserialization will result in the raw source messages that trigger the topology to be send to the DLQ topic. The processing might or might not continue depending of the configuration of the processing.exception.handler, default.production.exception.handler and default.deserialization.exception.handler configurations

public static final String ERRORS_DEADLETTERQUEUE_TOPIC_NAME_CONFIG = "errors.deadletterqueue.topic.name";

.define(ERRORS_DEADLETTERQUEUE_TOPIC_NAME_CONFIG, // required with no default value
       Type.STRING,
       null, /* default */
       Importance.HIGH,
       ERRORS_DEADLETTERQUEUE_TOPIC_NAME_DOC)

...

• Tests to ensure the backward compatibility of the ProductionExceptionHandler class
• Tests to ensure that default exception handlers are sending record to the DLQ topic if the DLQ topic name is set
• Ensure that failure to send the DLQ record kills the StreamThread
• Ensure that punctuator triggered exceptions are producing the expected payload

Rejected Alternatives

• Sending multiple DLQ record for a single issue.
• Managing DeadLetterQueue directly in the DSL by extending the KStreams interface.
• Providing no default implementation to build the Dead letter queue record and delegating this task to the user.
• Only providing exception and metadata information in the default DLQ implementation.
• Adding a new interface, that could be overload overloaded by the user, to build the DLQ recordrecords.