lianetm commented on PR #16686: URL: https://github.com/apache/kafka/pull/16686#issuecomment-2450633839
Hey @kirktrue, yes, your sketch does reflect what I described I had in mind (close => run callbacks no matter timeout/interrupt + best effort to send leave request). Do you maybe have a take on this approach @chia7712 , thoughts? Also totally agree with the downsides. The subscription state is the one I would think a bit more about, but without blocking this because any improvement there wouldn't affect the decoupling between the callbacks and send leave request we're proposing. My initial take is that it's not that dangerous given that we're closing anyways and can be maybe seen as a best effort too? We don't perform any action on that set of assigned partitions on close other than the callback so that one could be the only one affected: we could definitely have failures in the callback if we provide a set of assigned partitions to revoke/lost, taken from the app thread, and that changes in the background and removes them from the assignment. We can live with this edge case on close as a best effort to run callbacks with the latest known assignment, or we can come up with something (either way, it would build on top of the sketch above) -- 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