Hi Martin, The behavior is certainly strange. I think it's been kept this long because we've been loathe to break backwards compatibility. We'd need a KIP to change it at this point and we'd have to think through how to gracefully enable connector developers and Kafka Connect cluster administrators to use the new behavior, which is possible but just takes time to think through all the details.
One workaround you can use is to catch exceptions your connector might want to throw from SinkTask::preCommit and, if you actually want them to fail the task instead, throw them from SinkTask::put. Obviously this isn't ideal but it gets the job done for the most part. Cheers, Chris On Tue, Mar 31, 2026, 09:59 Martin Andersson <[email protected]> wrote: > Hello everyone. I'd like to ask a question about exception handling in > the connect framework for sink tasks. > > I noticed something that appears a bit odd when looking through the > code that commits offsets in the WorkerSinkTask, specifically when the > task preCommit() is called (currently > org/apache/kafka/connect/runtime/WorkerSinkTask.java:444 in the trunk > branch). > > If preCommit() throws an exception, it is assumed that the exception > is of such a nature that the correct way to handle it is to rewind to > last committed offsets. > > This is in contrast to how exception handling is done when calling > task.put(); there we explicitly check if the exception is a > RetriableException and if not we kill the task. > > Why do we not do something similar when calling task.preCommit() ? > I.e. check if any exception is a RetriableException and kill the task > if this is not the case. > > I'd also argue that catching Throwable the way we do is an > anti-pattern that is explicitly discouraged in the java documentation, > but that's another matter. > > Regards, > Martin >
