Page History

...

This KIP extends the applicability of the existing ProcessingExceptionHandler to GlobalKTable processors. Currently, this exception handler only applies to regular stream processing (KStream/KTable). After this KIP, the same handler will also handle processing exceptions in GlobalKTable. The feature is gated behind a configuration flag to prevent unexpected behaviour in existing handler implementations that may not be designed to handle GlobalKTable exceptions, which could cause crashes or undesired side effects. This provides a safe migration path for users to test and adapt their exception handling logic.

Exception Handling Scope

After this KIP, the ProcessingExceptionHandler configured via `default.processing.exception.handler` will be invoked for:

  - KStream processing exceptions (existing)
  - KTable processing exceptions (existing)
  - GlobalKTable processing exceptions (new capability added by this KIP)

Current State

Currently, while DeserializationExceptionHandler is passed to both regular stream tasks and global state update tasks, ProcessingExceptionHandler is only passed to regular stream tasks, resulting in unhandled processing exceptions for GlobalKTable processors.

Proposed Extension

The infrastructure for configuration and instantiation of ProcessingExceptionHandler already exists. However, it is currently only passed to regular stream tasks, not to global state update tasks. This KIP extends the existing pattern to pass ProcessingExceptionHandler to GlobalStateUpdateTask, mirroring how DeserializationExceptionHandler is already passed to both regular and global tasks. This enables exception handling during GlobalKTable processor execution.

Implementation

Add ProcessingExceptionHandler as a constructor parameter to GlobalStateUpdateTask and pass it to processor initialisation, mirroring the existing DeserializationExceptionHandler implementation.

Limitation

In this KIP, DLQ records returned by the handler will be logged but NOT sent to Kafka for GlobalKTable processors. This is because GlobalKTable processing does not currently have producer infrastructure. We will cover DLQ in a separate KIP. 

...