ShivsundarR opened a new pull request, #20135: URL: https://github.com/apache/kafka/pull/20135
https://issues.apache.org/jira/browse/KAFKA-19485 Bug : There is a bug in `ShareConsumeRequestManager` where we are adding acknowledgements on initial `ShareSession` epoch even after checking for it. Added fix to only include acknowledgements in the request if we have to, PR also adds the check at another point in the code where we could potentially be sending such acknowledgements. One of the cases could be when metadata is refreshed with empty topic IDs after a broker restart. This means leader information would not be available on the node. - Consumer subscribed to a partition whose leader was node-0. - Broker restart happens and node-0 is elected leader again. Broker starts a new `ShareSession`. - Background thread sends a fetch request with **non-zero** epoch. - Broker responds with `SHARE_SESSION_NOT_FOUND`. - Client updates session epoch to 0 once it receives this error. - Client updates metadata but receives empty metadata response. (Leader unavailable) - Application thread processing the previous fetch, completes and sends acks to piggyback on next fetch. - Next fetch will send the piggyback acknowledgements on the fetch for previously subscribed partitions resulting in error from broker ("`Acknowledge data present on initial epoch`"). (Currently we attempt to send even if leader is unavailable). **Fix** : Add a check before sending out acknowledgments if we are on an initial epoch. Added unit test covering the above scenario. -- 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
