lucasbru commented on PR #13876: URL: https://github.com/apache/kafka/pull/13876#issuecomment-1600924404
> 1. We might end up breaking customer's application code for exception handling with this change. What is our plan to prevent the inadvertent impact to customer's code on upgrade? > 2. This should probably be accompanied with changes in docs and notable change section for 3.6.0 - [kafka.apache.org/documentation.html#upgrade_350_notable](https://kafka.apache.org/documentation.html#upgrade_350_notable) @divijvaidya - To quote the accepted KIP, "This is a pure client side change which only affects the resiliency of new Producer client and Streams. For customized EOS use case, user needs to change their exception catching logic to take actions against their exception handling ... However, all the thrown exceptions' base type would still be KafkaException, so the effect should be minimal." However, I think you have a point that in the case of `ProducerFencedException` / `InvalidProducerEpochException`, we should be careful, as it is something that the user may catch frequently. And the KIP itself seems to have two conflicting views on this, authored by two different developers @abbccdda and @guozhangwang . In the original form, the KIP proposed to never wrap fatal errors, while the updated version proposed to wrap `ProducerFencedException` and `InvalidProducerEpochException`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
