Thanks, Lucas, for the feedback. I have addressed all the points mentioned above and updated the KIP. Thanks and Regards Arpit Goyal 8861094754
On Fri, Feb 20, 2026 at 3:12 PM Lucas Brutschy via dev <[email protected]> wrote: > Hi Arpit! > > This mostly looks good to me. > > lb3: How about processing.exception.handler.global.enabled instead of > default.processing.exception.handler.invoke.for.global. > lb4: Matthias explicitly asked for the KIP to state that handleError() > (not the deprecated handle()) will be used. I did not see that in the > text. > lb5: For the DLQ case, KIP still doesn't specify what is logged — full > record content (key/value) or just metadata (topic, partition, offset, > headers). > lb6: nit: Title seems a bit misleading actually. it's not introducing > a ProcessExceptionalHandler for GlobalThread, more like ""Extend > ProcessingExceptionHandler to GlobalKTable processors" > > I think we can accept it for 4.3, but maybe take a look at these > suggestions before that. > > Cheers, > Lucas > > > On Mon, Feb 16, 2026 at 5:59 PM Arpit Goyal <[email protected]> > wrote: > > > > Thanks, Matthias and Lucas, for the input. I have updated the KIP with > the > > deprecated config detail. > > Thanks and Regards > > Arpit Goyal > > 8861094754 > > > > > > On Thu, Feb 12, 2026 at 11:50 AM Arpit Goyal <[email protected]> > > wrote: > > > > > Yes I do agree on having a deprecated config. If everyone is aligned i > > > would update the KIP. > > > > > > Thanks and Regards > > > Arpit Goyal > > > 8861094754 > > > > > > On Thu, 12 Feb, 2026, 10:04 am Matthias J. Sax, <[email protected]> > wrote: > > > > > >> Yes, that's the idea. > > >> > > >> -Matthias > > >> > > >> On 2/11/26 4:44 PM, Arpit Goyal wrote: > > >> > Thanks, Lucas. Just to confirm, we are suggesting a kind of feature > flag > > >> > config for this KIP, which if enabled then only global processor > would > > >> > use the existing handler otherwise restore to default > implementation. > > >> > Thanks and Regards > > >> > Arpit Goyal > > >> > 8861094754 > > >> > > > >> > > > >> > On Thu, Feb 12, 2026 at 1:02 AM Lucas Brutschy via dev < > > >> [email protected]> > > >> > wrote: > > >> > > > >> >> Hi, > > >> >> > > >> >> I agree that this change could cause the processing error exception > > >> >> handler to crash under very specific circumstances. I think it's a > > >> >> fairly rare case, but since we are raising this as a feature, not > as a > > >> >> bug fix, you are right that we should follow the proposed route of > new > > >> >> deprecated configuration to be on the safe side. > > >> >> > > >> >> Cheers, > > >> >> Lucas > > >> >> > > >> >> > > >> >> On Wed, Feb 11, 2026 at 2:48 PM Arpit Goyal < > [email protected]> > > >> >> wrote: > > >> >>> > > >> >>> Thanks, Matthias, for the valuable input. > > >> >>> Yes, it may crash, depending on the existing handler > implementation, > > >> or > > >> >>> even lead to false information if alerting/logging is implemented > in > > >> the > > >> >>> handler. > > >> >>> But what I feel is that even if the handler crashes in the new > > >> >>> implementation, we are no worse off than the current state, where > > >> >>> GlobalKTable exceptions already crash or shut down the > application. > > >> >>> > > >> >>> Thanks and Regards > > >> >>> Arpit Goyal > > >> >>> 8861094754 > > >> >>> > > >> >>> > > >> >>> On Wed, Feb 11, 2026 at 1:39 PM Matthias J. Sax <[email protected] > > > > >> >> wrote: > > >> >>> > > >> >>>> Arpit, > > >> >>>> > > >> >>>> I was just re-reading the KIP, and I am wondering if the proposed > > >> >> change > > >> >>>> is really fully backward compatible? The KIP says: > > >> >>>> > > >> >>>>> This change is fully backward compatible: > > >> >>>>> - Applications without a configured handler experience no > > >> behavior > > >> >>>> change > > >> >>>>> - Applications with a configured handler automatically get > > >> >>>> GlobalKTable support > > >> >>>> > > >> >>>> The second point seems to be a change in behavior though? In the > very > > >> >>>> extreme case, the handler code might not be prepared for this > case, > > >> and > > >> >>>> could crash, or cause undesired side-effects? > > >> >>>> > > >> >>>> So I am wondering, if we would actually need a config which by > > >> default > > >> >>>> would keep this new feature disabled, and user would actively > need to > > >> >>>> change the config to enable it? > > >> >>>> > > >> >>>> If we go this route, we could also immediately _deprecate_ this > new > > >> >>>> config (yes, it's a little odd to add a new config an deprecate > it > > >> >> right > > >> >>>> away, but we have done this in the past), informing users that > with > > >> >>>> Kafka Streams 5.0, the handler will be invoked for "global > Processor" > > >> >>>> errors by default (and it's not possible to turn it off any > longer). > > >> >>>> > > >> >>>> > > >> >>>> Maybe I am too worried here, but based on experience, users do > many > > >> >>>> unexpected things, and to guard ourselves against surprises, it > might > > >> >> be > > >> >>>> the safer option, to play it conservative? > > >> >>>> > > >> >>>> > > >> >>>> Thoughts? -- Before you make any changes to the KIP, let's hear > from > > >> >>>> others. I guess I can also be convinces that the propose change > is > > >> safe > > >> >>>> enough as-is, and introducing a config would be overkill... > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> -Matthias > > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> On 2/2/26 9:04 AM, Arpit Goyal wrote: > > >> >>>>> Hi Everyone > > >> >>>>> I initiated the voting thread for this KIP. > > >> >>>>> > > >> >>>>> Thanks and Regards > > >> >>>>> Arpit Goyal > > >> >>>>> 8861094754 > > >> >>>>> > > >> >>>>> On Tue, 27 Jan, 2026, 10:41 pm Arpit Goyal, < > > >> >> [email protected]> > > >> >>>>> wrote: > > >> >>>>> > > >> >>>>>> Thanks everyone for the input. Should I start voting on it ? > > >> >>>>>> > > >> >>>>>> Thanks and Regards > > >> >>>>>> Arpit Goyal > > >> >>>>>> 8861094754 > > >> >>>>>> > > >> >>>>>> On Tue, 27 Jan, 2026, 2:10 pm Arpit Goyal, < > > >> >> [email protected]> > > >> >>>>>> wrote: > > >> >>>>>> > > >> >>>>>>> Thanks Matthias. > > >> >>>>>>> That makes sense. Client can use the single handler > > >> >> implementation to > > >> >>>>>>> support error handling for both Stream Thread and Global > thread. > > >> >> There > > >> >>>> is > > >> >>>>>>> no need to introduce ThreadType parameter or another > configuration > > >> >> for > > >> >>>> the > > >> >>>>>>> same. > > >> >>>>>>> @Lucas Brutschy <[email protected]> It must answered > your > > >> >> query > > >> >>>> ? > > >> >>>>>>> > > >> >>>>>>> Thanks and Regards > > >> >>>>>>> Arpit Goyal > > >> >>>>>>> 8861094754 > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>> On Tue, Jan 27, 2026 at 11:43 AM Matthias J. Sax < > > >> [email protected] > > >> >>> > > >> >>>>>>> wrote: > > >> >>>>>>> > > >> >>>>>>>> I don't think we would need multiple handlers. The handler is > > >> >> invoked > > >> >>>>>>>> passing in `ErrorHandlerContext` parameter, which provides > enough > > >> >>>>>>>> information to distinguish the case (eg, topic(), > > >> >> processorNodeId(), > > >> >>>> and > > >> >>>>>>>> taskId()), so users can implement different logic inside the > same > > >> >>>>>>>> handler for the different cases if necessary. > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> -Matthias > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> On 1/23/26 10:05 AM, Arpit Goyal wrote: > > >> >>>>>>>>> Thanks Bill and Lucas for the feedback. > > >> >>>>>>>>> > > >> >>>>>>>>> LB1: I was wondering precisely what we are logging in the > DLQ > > >> >> case. > > >> >>>> Do > > >> >>>>>>>>> you intend to log the full record content to > make he > > >> >>>> record > > >> >>>>>>>> content > > >> >>>>>>>>> recoverable, or only some metadata. I suppose > it's > > >> the > > >> >>>>>>>> latter. > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> > Since GlobalKTable lacks producer infrastructure, > DLQ > > >> >> records > > >> >>>>>>>> will be > > >> >>>>>>>>> logged with full metadata but NOT sent to a Kafka topic > > >> >>>>>>>>> LB2: Maybe I missed it (also not super fluent in that > part of > > >> >> the > > >> >>>>>>>>> code), but will the implementers of the > > >> >>>>>>>>> `ProcessExceptionalHandler` be > > >> >>>>>>>>> able to tell whether the error originated from > a > > >> >>>>>>>> globalThread or a > > >> >>>>>>>>> StreamsThread? The implementer may want to > > >> specialize > > >> >>>>>>>> handling for > > >> >>>>>>>>> each case. This is not a must, but would be a > nice > > >> to > > >> >> have > > >> >>>>>>>> for > > >> >>>>>>>>> sure. > > >> >>>>>>>>> > > >> >>>>>>>>> >. Great question! We have two options here > > >> >>>>>>>>> Option 1: Single Handler Configuration > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> Users define one implementation of > > >> >>>>>>>>> ProcessingExceptionHandler that handles errors for all > stream > > >> >> types > > >> >>>>>>>>> (KStream, KTable, and GlobalKTable). This maintains > > >> >>>>>>>>> consistency with the existing > > >> >>>>>>>>> DeserializationExceptionHandler pattern. > > >> >>>>>>>>> Limitation: This will enforce the same handling > > >> >> behavior > > >> >>>> for > > >> >>>>>>>>> global exception handling that we defined for KStream > processing > > >> >>>>>>>> exception > > >> >>>>>>>>> handling. This keeps things > > >> >>>>>>>>> simple but is not flexible > enough > > >> >> for > > >> >>>>>>>> users who > > >> >>>>>>>>> may want different behavior for GlobalKTable. > > >> >>>>>>>>> Option 2: Separate Optional Configuration > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> Introduce a new optional > > >> >> configuration: > > >> >>>>>>>>> global.processing.exception.handler. If configured, it > applies > > >> >>>>>>>> specifically > > >> >>>>>>>>> to GlobalKTable processing errors; if not > > >> >>>>>>>>> configured, exceptions bubble > up > > >> to > > >> >> the > > >> >>>>>>>> uncaught > > >> >>>>>>>>> exception handler (maintaining current behavior and backward > > >> >>>>>>>>> compatibility). > > >> >>>>>>>>> Limitation: Requires two configuration > properties > > >> >> if > > >> >>>>>>>> users want > > >> >>>>>>>>> exception handling for both regular streams and > GlobalKTable. > > >> >>>>>>>>> > > >> >>>>>>>>> With Option 1 - ProcessExceptionalHandler > does > > >> not > > >> >>>> have a > > >> >>>>>>>> way > > >> >>>>>>>>> to identify which thread is invoking it as of now. We may > need > > >> to > > >> >>>>>>>> introduce > > >> >>>>>>>>> ThreadType(Stream or Global) in errorHandlerContext with > > >> >> ThreadType > > >> >>>>>>>>> information. > > >> >>>>>>>>> With Option 2 - Client would always be aware > of > > >> the > > >> >>>> class > > >> >>>>>>>> it > > >> >>>>>>>>> has implemented for GlobalKTables. > > >> >>>>>>>>> > > >> >>>>>>>>> Thanks and Regards > > >> >>>>>>>>> Arpit Goyal > > >> >>>>>>>>> 8861094754 > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> On Fri, Jan 23, 2026 at 9:43 PM Bill Bejeck < > [email protected] > > >> > > > >> >>>>>>>> wrote: > > >> >>>>>>>>> > > >> >>>>>>>>>> Hi All, > > >> >>>>>>>>>> > > >> >>>>>>>>>> Thanks for the KIP! Makes sense to me and helps make KS > more > > >> >> robust. > > >> >>>>>>>>>> I don't have any additional comments beyond what's been > said so > > >> >> far. > > >> >>>>>>>>>> > > >> >>>>>>>>>> -Bill > > >> >>>>>>>>>> > > >> >>>>>>>>>> On Fri, Jan 23, 2026 at 5:52 AM Lucas Brutschy via dev < > > >> >>>>>>>>>> [email protected]> > > >> >>>>>>>>>> wrote: > > >> >>>>>>>>>> > > >> >>>>>>>>>>> Hi, > > >> >>>>>>>>>>> > > >> >>>>>>>>>>> Overall, this makes sense to me. Thanks for the KIP! > > >> >>>>>>>>>>> > > >> >>>>>>>>>>> LB1: I was wondering precisely what we are logging in the > DLQ > > >> >> case. > > >> >>>>>>>> Do > > >> >>>>>>>>>>> you intend to log the full record content to make he > record > > >> >> content > > >> >>>>>>>>>>> recoverable, or only some metadata. I suppose it's the > latter. > > >> >>>>>>>>>>> > > >> >>>>>>>>>>> LB2: Maybe I missed it (also not super fluent in that > part of > > >> >> the > > >> >>>>>>>>>>> code), but will the implementers of the > > >> >> `ProcessExceptionalHandler` > > >> >>>>>>>> be > > >> >>>>>>>>>>> able to tell whether the error originated from a > globalThread > > >> >> or a > > >> >>>>>>>>>>> StreamsThread? The implementer may want to specialize > handling > > >> >> for > > >> >>>>>>>>>>> each case. This is not a must, but would be a nice to > have for > > >> >>>> sure. > > >> >>>>>>>>>>> > > >> >>>>>>>>>>> Cheers, > > >> >>>>>>>>>>> Lucas > > >> >>>>>>>>>>> > > >> >>>>>>>>>>> On Thu, Jan 15, 2026 at 8:55 AM Arpit Goyal < > > >> >>>>>>>> [email protected]> > > >> >>>>>>>>>>> wrote: > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> Hi All, > > >> >>>>>>>>>>>> Looking for more inputs and feedback. This would help to > move > > >> >> this > > >> >>>>>>>> KIP > > >> >>>>>>>>>>>> forward. > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> Thanks and Regards > > >> >>>>>>>>>>>> Arpit Goyal > > >> >>>>>>>>>>>> 8861094754 > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> On Tue, 13 Jan, 2026, 2:17 pm Arpit Goyal, < > > >> >>>>>>>> [email protected]> > > >> >>>>>>>>>>> wrote: > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>>> Thanks for the response Matthias. > > >> >>>>>>>>>>>>> I have updated the KIP to include KIP-1034 handleError() > > >> >>>> automatic > > >> >>>>>>>>>>>>> backward compatibility. DLQ part I already mentioned > under > > >> >> the > > >> >>>>>>>>>>> Limitation > > >> >>>>>>>>>>>>> section. Let me know if it needs to be improved further. > > >> >>>>>>>>>>>>> Thanks and Regards > > >> >>>>>>>>>>>>> Arpit Goyal > > >> >>>>>>>>>>>>> 8861094754 > > >> >>>>>>>>>>>>> > > >> >>>>>>>>>>>>> > > >> >>>>>>>>>>>>> On Tue, Jan 13, 2026 at 5:05 AM Matthias J. Sax < > > >> >>>> [email protected]> > > >> >>>>>>>>>>> wrote: > > >> >>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> Thanks for the clarification. Make sense to me. > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> Might be good to add some of these details (no code > > >> >> reference to > > >> >>>>>>>>>>>>>> `ProcessorNode` etc necessary as it's impl detail) to > the > > >> >> KIP. > > >> >>>> Ie, > > >> >>>>>>>>>>> state > > >> >>>>>>>>>>>>>> explicitly that the new handleError() will be used and > that > > >> >> it > > >> >>>>>>>>>>> provides > > >> >>>>>>>>>>>>>> backward compatibility automatically based on it's > current > > >> >>>>>>>>>>> implementaion > > >> >>>>>>>>>>>>>> from KIP-1034. > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> And that DLQ records, if returned, would be ignored and > > >> >> dropped > > >> >>>>>>>> and > > >> >>>>>>>>>> a > > >> >>>>>>>>>>>>>> warning is logged about it for this case. > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> -Matthias > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> On 1/12/26 2:29 AM, Arpit Goyal wrote: > > >> >>>>>>>>>>>>>>> Thank you for the detailed questions! Let me clarify > the > > >> >>>>>>>>>>> implementation > > >> >>>>>>>>>>>>>>> approach: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Which Method Will Be Called? > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> GlobalThread will call the NEW handleError() > method > > >> >> (not > > >> >>>> the > > >> >>>>>>>>>>>>>> deprecated > > >> >>>>>>>>>>>>>>> handle()). > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Key Point: The exception handler is not called > > >> >> directly by > > >> >>>>>>>>>>>>>> GlobalThread. > > >> >>>>>>>>>>>>>>> Instead, it's called by ProcessorNode.process(), which > > >> >> already > > >> >>>>>>>>>>> invokes > > >> >>>>>>>>>>>>>>> handleError() for regular processors. > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> The implementation is straightforward: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Current code > (GlobalStateUpdateTask.initTopology - > > >> >> line > > >> >>>> 161): > > >> >>>>>>>>>>>>>>> node.init((InternalProcessorContext) > > >> >>>> this.processorContext); > > >> >>>>>>>>>> // > > >> >>>>>>>>>>> No > > >> >>>>>>>>>>>>>>> handler passed > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Proposed change: > > >> >>>>>>>>>>>>>>> node.init((InternalProcessorContext) > > >> >>>> this.processorContext, > > >> >>>>>>>>>>>>>>> processingExceptionHandler); // Pass handler > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Once the handler is passed to ProcessorNode, the > > >> same > > >> >> code > > >> >>>>>>>> path > > >> >>>>>>>>>>> that > > >> >>>>>>>>>>>>>>> handles exceptions for regular KStream/KTable > processors > > >> >>>>>>>>>>>>>>> (ProcessorNode.process() line 236) will automatically > > >> >> handle > > >> >>>>>>>>>>>>>> GlobalKTable > > >> >>>>>>>>>>>>>>> exceptions: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Response response = > > >> >>>>>>>>>>>>>>> > > >> processingExceptionHandler.handleError(errorHandlerContext, > > >> >>>>>>>>>> record, > > >> >>>>>>>>>>>>>>> exception); > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> There's no separate code path for GlobalThread > - it > > >> >> reuses > > >> >>>>>>>> the > > >> >>>>>>>>>>>>>> existing > > >> >>>>>>>>>>>>>>> ProcessorNode exception handling mechanism. > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Backward Compatibility > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> The handleError() method provides automatic > backward > > >> >>>>>>>>>>> compatibility > > >> >>>>>>>>>>>>>> via > > >> >>>>>>>>>>>>>>> its default implementation: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> default Response handleError(...) { > > >> >>>>>>>>>>>>>>> return new > Response(Result.from(handle(...)), > > >> >>>>>>>>>>>>>>> Collections.emptyList()); > > >> >>>>>>>>>>>>>>> } > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> - If users implement the old handle() method: > > >> >>>> handleError() > > >> >>>>>>>>>>>>>> delegates to > > >> >>>>>>>>>>>>>>> it automatically > > >> >>>>>>>>>>>>>>> - If users implement the new handleError() > method: > > >> >> it's > > >> >>>> used > > >> >>>>>>>>>>> directly > > >> >>>>>>>>>>>>>>> - No code changes required for existing > applications > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Dead Letter Queue (DLQ) Support > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> This is where GlobalKTable differs from regular > > >> >>>> processors: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> The Limitation: GlobalThread does not have a > > >> >> Producer, so > > >> >>>> it > > >> >>>>>>>>>>> cannot > > >> >>>>>>>>>>>>>> send > > >> >>>>>>>>>>>>>>> DLQ records to Kafka. > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> Proposed Approach: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> 1. For KIP-1270: When ProcessorNode detects DLQ > > >> >> records > > >> >>>> but > > >> >>>>>>>> the > > >> >>>>>>>>>>>>>> context > > >> >>>>>>>>>>>>>>> doesn't support RecordCollector (i.e., GlobalThread), > it > > >> >> will > > >> >>>> log > > >> >>>>>>>>>> a > > >> >>>>>>>>>>>>>> warning > > >> >>>>>>>>>>>>>>> instead of sending: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> log.warn("Dead letter queue records cannot be > sent > > >> for > > >> >>>>>>>>>>> GlobalKTable > > >> >>>>>>>>>>>>>>> processors " + > > >> >>>>>>>>>>>>>>> "(no producer available). DLQ support > for > > >> >>>>>>>> GlobalKTable > > >> >>>>>>>>>>> will > > >> >>>>>>>>>>>>>> be > > >> >>>>>>>>>>>>>>> addressed in a future KIP. " + > > >> >>>>>>>>>>>>>>> "Record details logged: topic={}, > > >> >> headers={}", > > >> >>>> ...); > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> 2. Future KIP: Full DLQ support for GlobalKTable > > >> >> (requires > > >> >>>>>>>>>> adding > > >> >>>>>>>>>>>>>>> Producer infrastructure) will be proposed separately, > as > > >> >> it's a > > >> >>>>>>>>>>> larger > > >> >>>>>>>>>>>>>>> architectural change. > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> How This Avoids User Confusion > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> 1. Single handler for all processors: Users > > >> configure > > >> >> ONE > > >> >>>>>>>>>>>>>>> ProcessingExceptionHandler that works for both > regular and > > >> >>>> global > > >> >>>>>>>>>>>>>> processors > > >> >>>>>>>>>>>>>>> 2. Consistent behavior: Result.RESUME continues, > > >> >>>> Result.FAIL > > >> >>>>>>>>>>> stops - > > >> >>>>>>>>>>>>>> same > > >> >>>>>>>>>>>>>>> for both > > >> >>>>>>>>>>>>>>> 3. Clear limitation: DLQ records are logged (not > > >> >> sent) for > > >> >>>>>>>>>>>>>> GlobalKTable, > > >> >>>>>>>>>>>>>>> with explicit warning message > > >> >>>>>>>>>>>>>>> 4. Documentation: Config docs will clearly > state DLQ > > >> >>>> sending > > >> >>>>>>>>>>>>>> limitation > > >> >>>>>>>>>>>>>>> for GlobalKTable > > >> >>>>>>>>>>>>>>> Thanks and Regards > > >> >>>>>>>>>>>>>>> Arpit Goyal > > >> >>>>>>>>>>>>>>> 8861094754 > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> On Mon, Jan 12, 2026 at 7:40 AM Matthias J. Sax < > > >> >>>>>>>> [email protected] > > >> >>>>>>>>>>> > > >> >>>>>>>>>>>>>> wrote: > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> Thanks for the KIP Arpit. > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> Can you elaborate a little bit more on details? With > the > > >> >> newly > > >> >>>>>>>>>>> added > > >> >>>>>>>>>>>>>> DLQ > > >> >>>>>>>>>>>>>>>> support for regular `Processor`, the existing > > >> >>>>>>>>>>>>>>>> `ProcessingHandlerResponse` and corresponding method > > >> >>>> `handle()` > > >> >>>>>>>>>> are > > >> >>>>>>>>>>>>>>>> deprecated with upcoming 4.2 release. > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> Thus, from AK 4.2+ going forward, users are expected > to > > >> >> not > > >> >>>>>>>>>>> implement > > >> >>>>>>>>>>>>>>>> the old `handle()` (even if it's still supported, as > long > > >> >> as > > >> >>>> the > > >> >>>>>>>>>>> new > > >> >>>>>>>>>>>>>>>> `handleError` is not overwritten). > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> Are you proposing, for now, to only add support for > the > > >> >>>>>>>>>> deprecated > > >> >>>>>>>>>>>>>>>> `handle()` method, ie, the new `handleError()` method > > >> >> would > > >> >>>> not > > >> >>>>>>>>>> be > > >> >>>>>>>>>>>>>>>> called by the global-thread code? If yes, this might > be > > >> >>>>>>>> confusing > > >> >>>>>>>>>>> for > > >> >>>>>>>>>>>>>>>> users? > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> If you do not propose this, would it imply that the > > >> >>>>>>>> global-thread > > >> >>>>>>>>>>> code > > >> >>>>>>>>>>>>>>>> would call the new `handlerError()` method? For this > > >> >> case, the > > >> >>>>>>>>>>> question > > >> >>>>>>>>>>>>>>>> is what the runtime would do if users try to use the > DLQ > > >> >>>>>>>> feature? > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> Overall, it's unclear to me what you propose in > detail > > >> >> and how > > >> >>>>>>>> we > > >> >>>>>>>>>>> can > > >> >>>>>>>>>>>>>>>> avoid to confuse users, keep it backward compatible, > and > > >> >> make > > >> >>>> it > > >> >>>>>>>>>>> easy > > >> >>>>>>>>>>>>>> to > > >> >>>>>>>>>>>>>>>> understanding how the handler will work. > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> -Matthias > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> On 1/10/26 8:33 AM, Arpit Goyal wrote: > > >> >>>>>>>>>>>>>>>>> Hi Team > > >> >>>>>>>>>>>>>>>>> Just reaching out again.Need your inputs to move it > > >> >> forward > > >> >>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>> Thanks and Regards > > >> >>>>>>>>>>>>>>>>> Arpit Goyal > > >> >>>>>>>>>>>>>>>>> 8861094754 > > >> >>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>> On Thu, 8 Jan, 2026, 10:03 pm Arpit Goyal, < > > >> >>>>>>>>>>> [email protected]> > > >> >>>>>>>>>>>>>>>> wrote: > > >> >>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> Hi All, > > >> >>>>>>>>>>>>>>>>>> I would like to start a discussion for KIP-1270. > This > > >> >> KIP > > >> >>>>>>>>>>> extends > > >> >>>>>>>>>>>>>>>>>> ProcessingExceptionHandler support to GlobalKTable > > >> >>>> processors, > > >> >>>>>>>>>>>>>> enabling > > >> >>>>>>>>>>>>>>>>>> consistent exception handling across all stream > > >> >> processing > > >> >>>>>>>>>> types. > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> * Current Behavior* > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> When a processing exception occurs in a > > >> >> GlobalKTable > > >> >>>>>>>>>>> processor: > > >> >>>>>>>>>>>>>>>>>> - The exception propagates to > GlobalStreamThread > > >> >>>>>>>>>>>>>>>>>> - The GlobalStreamThread terminates > > >> >>>>>>>>>>>>>>>>>> - The entire Kafka Streams application shuts > > >> down > > >> >>>>>>>>>>>>>>>>>> - No user-configurable exception handling is > > >> >> available > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> * Proposed Behavior* > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> After this KIP, when a processing exception > > >> >> occurs in > > >> >>>> a > > >> >>>>>>>>>>>>>> GlobalKTable > > >> >>>>>>>>>>>>>>>>>> processor: > > >> >>>>>>>>>>>>>>>>>> - The configured > > >> >>>> ProcessingExceptionHandler.handleError() > > >> >>>>>>>>>>> will be > > >> >>>>>>>>>>>>>>>> invoked > > >> >>>>>>>>>>>>>>>>>> - If the handler returns Result.RESUME, > > >> processing > > >> >>>>>>>>>> continues > > >> >>>>>>>>>>>>>> with the > > >> >>>>>>>>>>>>>>>>>> next record > > >> >>>>>>>>>>>>>>>>>> - If the handler returns Result.FAIL, the > > >> >> exception > > >> >>>>>>>>>>> propagates > > >> >>>>>>>>>>>>>> (same > > >> >>>>>>>>>>>>>>>> as > > >> >>>>>>>>>>>>>>>>>> current behavior) > > >> >>>>>>>>>>>>>>>>>> - If no handler is configured, behavior > remains > > >> >>>> unchanged > > >> >>>>>>>>>>>>>> (backward > > >> >>>>>>>>>>>>>>>>>> compatible) > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> KIP: > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>> > > >> >>>> > > >> >> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1270%3A+Introduce+ProcessExceptionalHandler+for+GlobalThread > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>>> Thanks and Regards > > >> >>>>>>>>>>>>>>>>>> Arpit Goyal > > >> >>>>>>>>>>>>>>>>>> 8861094754 > > >> >>>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>> > > >> >>>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>>>> > > >> >>>> > > >> >>>> > > >> >> > > >> > > > >> > > >> >
