...

We aim at enabling users to ignore the `send(ProducerRecord)` errors by defining a new `commitTransaction` method. The new method clears the latest error produced by `send(ProducerRecord)` and transits the transaction back from the error state.  In order to keep it safe, the change is applied to transactions with no unflushed record. Therefore, the user must explicitly call `flush()` before calling the newly defined  `commitTransaction`. adding an input parameter to the `send` method so that the user is able to determine not going to the error state by a poison pill record. 
The following list categorizes all types of errors that cause a transaction to fail. The category with a beside specifies the cases that the new `send` API is going to cover. 

• producer-side errors
  • recoverable, such as `RecordTooLargeException`  
  • irrecoverable, such as `ProducerFencedException`
• broker-side errors

Currently, producer-side recoverable errors (the KIP's target category) prevent a record from being added to a batch. They additionally make a transition to an `error` state, which causes the transaction to fail. This KIP provides the possibility to commit a transaction successfully in presence of such errors. Obviously, the problematic records are not added to the batch, but the transition to the `error` state is not done. In other words, with the new `send` API, the transaction does not fail because of a single poison pill record that is not even present in the batch. Obviously, the transaction can still fail due to other types of errors (for example, broker-side errors).

Public Interfaces

If the user 1) is performing a transaction and 2) passes the `CommitOption` `TxnSendOption` with the value `CLEAR`IGNORE_SEND_ERRORS` to the `send` method, it commits the transaction even in the presence of `send()` errors, any poison pill record is excluded from the batch, and the transaction is committed successfully. Note that if the user sets the `TxnSendOption` to `IGNORE_SEND_ERRORS` outside of a transaction, the overloaded `send` method throws an `IllegalStateException`.

     /**
public Future<RecordMetadata> send(ProducerRecord<K, V> record, * This method should only be called if there are no pending writes, i.e., only after calling {@link #flush()}.
     * If there are any errors in sending messages to topics, these errors can be cleared by passing {@link CommitOption#CLEAR_SEND_ERRORS},
     * allowing the transaction to be committed even in case of data loss.
     * <p>Callback callback, TxnSendOption option) {}


     *public Ifenum this method is used while there are pending sends, the send errors cannot be cleared.
 TxnSendOption {
     
     * @param commitOption The method option
     *
     * @throws IllegalStateException if no transactional.id has been configured or no transaction has been started
     * @throws ProducerFencedException fatal error indicating another producer with the same transactional.id is active
     * @throws org.apache.kafka.common.errors.UnsupportedVersionException fatal error indicating the broker
     *         does not support transactions (i.e. if its version is lower than 0.11.0.0)
     * @throws org.apache.kafka.common.errors.AuthorizationException fatal error indicating that the configured
     *         transactional.id is not authorized. See the exception for more details
     * @throws org.apache.kafka.common.errors.InvalidProducerEpochException if the producer has attempted to produce with an old epoch
     *         to the partition leader. See the exception for more details
     * @throws KafkaException if the producer has encountered a previous fatal or abortable error, or for any
     * /**
         * The irrecoverable {@link #send(ProducerRecord)} errors lead the transaction to the error state, which ends up an unsuccessful commit. 
        other unexpected error
     * @throws TimeoutException if the time taken for committing the transaction has surpassed <code>max.block.ms</code>.
     * @throws InterruptException if the thread is interrupted while blocked NONE,
     */


     public void commitTransaction(CommitOption option) throws ProducerFencedException {}

     public enum CommitOption {
        /**
         * Commits the ongoing transaction, flushing any unsent The records beforecausing actuallyirrecoverable committing
errors are excluded from      * the transaction. If any of the records sent in this transaction hit unrecoverable errors,
         * the transaction will not be committed.
         */
 batch and the transaction is committed successfully. 	
       NONE,
        /**
 Note to       * Commits the ongoing transaction, first clearing any errors from records already sent in
         * this transaction. If there are any unsent records flushed by this operation which hit 
         * unrecoverable errors, these errors will not be cleared and the transaction will not be 
         * committed.
         * <p>
         * To ensure there are no unsent records, you must call {@link #flush()} before
         * committing the transaction.
         */
        CLEAR_SEND_ERRORS
    use this, only in transactions. Otherwise {@link #send(ProducerRecord, Callback, TxnSendOption)} throws exception.
         */
        IGNORE_SEND_ERRORS
    }

We define the method in the interface as well. The `default` implementation helps with backward compatibility.

     /**
     * See {@link KafkaProducer#send(ProducerRecord, Callback, SendTxnOption)}
      */
    default void send(ProducerRecord record, Callback callback, SendTxnOption option) throws ProducerFencedException {}

Compatibility, Deprecation, and Migration Plan

...

Unit tests for `KafkaProducer` to show that the new feature works with different `send()` errors and exceptions such as RecordTooLargeException.

Rejected Alternatives

• Add a producer custom exception handler interface: see KIP-1038 and the discussions.
• Identify poison pill records application-side:  It is not efficient and sometimes not even doable. For example for identifying too-large-records the application must be aware of producer configs as well as serialization method, which is not feasible sometimes. More over, checking every single record's size before sending it to catch the bad record is an overhead considering that this check is done by Producer as well.
• Add the feature of clearing errors to `flush()`: `flush()` is not necessarily a transactional method + `AddPartition` is not done successfully in the next `send`.
• Add the feature of clearing errors to `commitTxn()`: `AddPartition` is not done successfully in the next `send`.
• `send()` throws ApiException: may break backward compatibility.
• No need of explicit `flush()` before calling `commitTransaction(commitOptions)` :  not safe + `AddPartition` is not done successfully in the next `send`
• The user must use ALOS instead of EOS in case they want to drop the poison pill records: ALOS can not guarantee not having duplicates.