This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Under Discussion

...

Over time, certain exceptions and methods within the Kafka Streams exception handling interfaces have been deprecated in favor of newer, more comprehensive alternatives. Retaining these deprecated elements can lead to confusion, and complicates future development and maintenance. This KIP proposes the removal of these specific deprecated exceptions and methods to streamline the API and improve code clarity.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• Binary log format

• The network protocol and api behavior

• Any class in the public packages under clientsConfiguration, especially client configuration

  • org/apache/kafka/common/serialization

  • org/apache/kafka/common

  • org/apache/kafka/common/errors

  • org/apache/kafka/clients/producer

  • org/apache/kafka/clients/consumer (eventually, once stable)

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

The removal will affect the public exceptions of Kafka Streams. Users who are still using the `BrokerNotFoundException` class or implementing/calling these specific deprecated methods will encounter compilation errors.

Proposed Changes

This KIP proposes to remove the following deprecated Kafka Streams exception class and methods:

Deprecated Class for Removal:

• org.apache.kafka.streams.errors.BrokerNotFoundException

Deprecated Methods for Removal:

• org.apache.kafka.streams.errors.DefaultProductionExceptionHandler.handle(final ProducerRecord<byte[], byte[]> record, final Exception exception)` and the interface method org.apache.kafka.streams.errors.ProductionExceptionHandler.handle(final ProducerRecord<byte[], byte[]> record, final Exception exception)
• org.apache.kafka.streams.errors.ProductionExceptionHandler.handleSerializationException(final ProducerRecord record, final Exception exception)
• org.apache.kafka.streams.errors.DeserializationExceptionHandler.handle(final ProcessorContext context, final ConsumerRecord<byte[], byte[]> record,final Exception exception)
•  org.apache.kafka.streams.errors.LogAndContinueExceptionHandler.handle(final ProcessorContext context, final ConsumerRecord<byte[], byte[]> record,final Exception exception)
• org.apache.kafka.streams.errors.LogAndFailExceptionHandler.handle(final ProcessorContext context, final ConsumerRecord<byte[], byte[]> record, finalException exception)

The BrokerNotFoundException class was deprecated in Kafka Streams 2.8 and it is no longer used internally. 
The listed methods were deprecated in Kafka Streams version 3.9, with newer handle methods (that include ErrorHandlerContext) provided as replacements.

The removal of these elements will simplify the interfaces and ensure users adopt the more robust exception handling mechanisms.

Compatibility, Deprecation, and Migration Plan

• Compatibility: This change is not backward compatible at the source code level for users who are still using the BrokerNotFoundException class or implementing/calling these specific deprecated methods.
• Deprecation: The BrokerNotFoundException was deprecated in Kafka Streams version 2.8. The listed methods were deprecated in KafkaStreams version 3.9.
  • Given that these elements were deprecated in earlier versions (2.8 and 3.9), a sufficient deprecation period has passed, making their removal appropriate.
• Migration Plan:
  • For BrokerNotFoundException: Users should remove any handling of this exception as it is no longer relevant.
  • For deprecated methods: Users are advised to migrate their code to use the non-deprecated handle methods that accept ErrorHandlerContext. For example:
    • Instead of DeserializationExceptionHandler.handle(ProcessorContext, ConsumerRecord, Exception), use DeserializationExceptionHandler.handle(ErrorHandlerContext, ConsumerRecord, Exception).
    • Instead of ProductionExceptionHandler.handle(ProducerRecord, Exception), use ProductionExceptionHandler.handle(ErrorHandlerContext,ProducerRecord, Exception).
    • Instead of ProductionExceptionHandler.handleSerializationException(ProducerRecord, Exception), use ProductionExceptionHandler.handleSerializationException(ErrorHandlerContext, ProducerRecord, Exception, SerializationExceptionOrigin).

Test Plan

This is a code cleanup. Existing test suite should catch any failures. Will add or update new unittests as needed.

Rejected Alternatives

N/AIf there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.