Handling network transient error on deserialization

[midovlvn]

Hi,

recently in scope of #3032 new sentence was added to paragraph in documentation
https://docs.spring.io/spring-kafka/reference/kafka/serdes.html#retrying-deserialization

The RetryingDeserializer uses a delegate Deserializer and RetryTemplate to retry deserialization when the delegate might have transient errors, such as network issues, during deserialization.
(...)
Starting with version 3.1.2, a RecoveryCallback can be set on the RetryingDeserializer optionally.

I can't find idea behind it, because the simplest solution for transient error is throw it away. The poll will be repeated and deserialization will work again. When transient error is solved, processing will continue.

I do not criticize other attempts, but I do not understand - maybe I missed something - why documentation describes custom retrying policy, when simple approach "do nothing" is good enough

[artembilan]

The RecoveryCallback is there for a situation when all the retry attempts are exhausted.
If your goal is do nothing, then you can provide respective RetryPolicy to not retry some specific exceptions.
From the framework perspective we cannot assume that some transient errors are false positive for all the use-case.
Therefore it is left with defaults and can be customized per use-case.