...

Proposed Changes

We propose a `AbortedTransactionalProduceException` `TransactionAbortedException` that will be thrown in case the transaction is aborted but still recoverable. This will allow users to check this exception and retry if needed.

As this will extend `KafkaException``ApiException`, users already catching `KafkaException` (which `ApiException` extends) will not be impacted and hence this is a backward compatible change.

...

public class TransactionAbortedException AbortedTransactionalProduceExceptionextendsextends KafkaExceptionApiException {

    private final static long serialVersionUID = 1L;

    public AbortedTransactionalProduceExceptionTransactionAbortedException(String message, Throwable cause) {
        super(message, cause);
    }

    public AbortedTransactionalProduceExceptionTransactionAbortedException(String message) {
        super(message);
    }

    public AbortedTransactionalProduceExceptionTransactionAbortedException() {
        super("Aborting transaction during production of batch.");
    }
}

...

• What impact (if any) will there be on existing users?
  • Existing users will see a new kind of exception that is still caught by their code since this will extend `KafkaException`
  If we are changing behavior how will we phase out the older behavior?
  • In the future, the `AbortedTransactionalProduceException` will not extend the `KafkaException` and the new Exception should be added to the method signature.`ApiException` and by extension `KafkaException`
• If we need special migration tools, describe them here.
  • None needed.
• When will we remove the existing behavior?
  • This could be removed in the release after this is adopted and mentioned clearly in the release notes.

...