lianetm commented on code in PR #18737:
URL: https://github.com/apache/kafka/pull/18737#discussion_r1944980202
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/CommitRequestManager.java:
##########
@@ -324,7 +323,7 @@ public CompletableFuture<Void>
maybeAutoCommitSyncBeforeRevocation(final long de
CompletableFuture<Void> result = new CompletableFuture<>();
OffsetCommitRequestState requestState =
- createOffsetCommitRequest(subscriptions.allConsumed(), deadlineMs);
+ createOffsetCommitRequest(latestPartitionOffsets, deadlineMs);
Review Comment:
This is a tricky one, but I wonder if there is a simple fix at a higher
level. At the moment we're triggering reconciliation freely in the background
(when polling all managers, polling the membershipMgr is the one triggering
it), and as I see it, that's probably what's conceptually wrong here? Should we
consider triggering reconciliations only when processing a PollEvent?
With that this situation here disappears, because we would be generating the
commit to revoke before any fetching happens (and even considering that the
commit needs to be retried, at that point we know we had marked the partition
as pending for revocation already, so no new fetches for it).
Seems conceptually right and simple, but I could be missing something. What
do you think?
--
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
