The Connector That Kept Retrying and Never Said So

A customer reported that their Kafka Connect MQ Sink connector looked completely healthy — no errors on the connector CR, no failed tasks — but no messages were reaching MQ. This had been going on for hours.

The logs told a different story: an MQ authentication failure, retried continuously, never escalated to the connector level.

The customer had already tried the usual levers — tuning the retry backoff, setting errors.tolerance to get the framework to give up after a while. Neither changed anything. They also opened a case with Confluent, who confirmed the underlying issue: errors.retry.timeout only governs the framework-managed stages of Kafka Connect (converters, SMTs). It has no visibility into a connector's own put() method. If put() throws a RetriableException without enforcing its own limit, Kafka Connect will keep redelivering the same batch indefinitely.

Why the timeout never kicked in

RetryWithToleranceOperator — the class Kafka Connect uses to enforce errors.retry.timeout — only wraps the ingestion-side stages: consumer record extraction, key/value conversion, header transformation. task.put() runs outside that wrapper entirely, so nothing in the framework is tracking how long it's been failing.