Your Spring Boot Kafka consumer stops consuming after processing a malformed message. How do you fix it?

Root cause depends on where it fails. If the @KafkaListener method throws, the container's DefaultErrorHandler (Spring Kafka 2.8+) retries with the default back off (9 retries, no delay, so ten attempts) and then only logs the record; the consumer stays stuck on one record when retries are effectively unlimited (for example FixedBackOff.UNLIMITED_ATTEMPTS or an ExponentialBackOff without a maxElapsedTime). A deserialization failure occurs before poll() returns, so Spring cannot handle it unless the deserializer is wrapped in ErrorHandlingDeserializer. Fix: 1) Configure a DefaultErrorHandler with a bounded back off and a dead-letter recoverer: factory.setCommonErrorHandler(new DefaultErrorHandler(new DeadLetterPublishingRecoverer(kafkaTemplate), new FixedBackOff(1000L, 3L))). By default the dead-letter record goes to <originalTopic>-dlt on the same partition, so that topic needs at least as many partitions. 2) Or use @RetryableTopic for non-blocking retries with a DLT (not supported for batch listeners). 3) For bad payloads, configure ErrorHandlingDeserializer around the real deserializer; it puts a DeserializationException in a header and the record goes to the error handler, which treats DeserializationException as not retryable by default. 4) Emergency fix: stop the consumers and run kafka-consumer-groups.sh --reset-offsets --shift-by 1 --execute (the group must be inactive; check the dry run first), accepting that the skipped record is never processed. 5) A good practice is to add error handling and a DLT from the start.

Expected key concepts: DefaultErrorHandler, DeadLetterPublishingRecoverer, FixedBackOff, ErrorHandlingDeserializer, DeserializationException, DLT, @RetryableTopic, shift-by, reset-offsets, BackOff, poll