lucasbru commented on PR #23500: URL: https://github.com/apache/kafka/pull/23500#issuecomment-5726606437
Closing this — on further analysis, the underlying premise was wrong. The epoch-ordering guard added here prevents `throttleConversionDelete` from ever installing its UNCERTAIN(-2) entry when a stale real-epoch entry from heartbeat backoff is still present for a group. But `isConversionDeleteThrottled` only recognizes an active window at that sentinel epoch, so this change silently defeats the throttle in exactly that case, reopening the tight `deleteTopology` retry loop against a failing plugin that the throttle exists to prevent (classic clients retry immediately on REBALANCE_IN_PROGRESS with no backoff of their own). The "clobbering" of the stale real-epoch entry that this PR set out to fix is intentional, documented behavior (see the javadoc on StreamsGroupTopologyDescriptionManager#throttleConversionDelete), not a bug — the cost is just losing an already-irrelevant attempt count on a chain that has no members left to consult it, which is far cheaper than reopening an unthrottled retry loop. Thanks for the review — the first comment here was the one that surfaced the regression. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
