Page History

...

1. If the Exception that is thrown is a ProducerFencedException, behave as we do today and do not invoke the ProductionExceptionHandler as these exceptions are self-healing.
2. If the Exception that is thrown is fatal will affect all records and should cause Streams to always fail. If so, then do not invoke the ProductionExceptionHandler because its result will have to be ignored. We should log that we're ignoring these exceptions at DEBUG level.
   1. The exceptions that meet this classification are:
      1. AuthenticationException
      2. AuthorizationException
      3. SecurityDisabledException
      4. InvalidTopicException
      5. UnknownServerException
      6. IllegalStateException
      7. OffsetMetadataTooLarge
      8. SerializationException

      9. TimeoutException when it occurs immediately on send due to a full buffer

3. If the Exception that is thrown meets neither of the above conditions, determine if sendException is already set. If so, do not invoke the ProductionExceptionHandler because this would mean that we've already invoked it and decided to FAIL. Invoking it again would just result in an ignored result.
4. If none of the conditions above is met, invoke the handle method in the ProductionExceptionHandler and check the result.
   1. If the result is CONTINUE, log a note at DEBUG that we received that result and are not failing Streams as a result. This ensures that it's not possible for a client developer to ship code that totally swallows errors without presenting any kind of activity in the log.
   2. If the result is FAIL, log a message at ERROR that we received that result and set sendException so Streams will fail.

...