Hi Mickael, Thanks for the KIP. It looks fine, there's a few details I think we should iron out.
1. Does it make sense to allow callers to retrieve translated offsets for all consumer groups, without having to specify a subset of group IDs at the call site? The only reason to reject this alternative that comes to mind right now is that the memory footprint of the resulting map may be too large in some cases, but it'd be nice to document this rationale if that's the case. 2. Based on the existing MirrorClient::remoteConsumerOffsets implementation, it looks like when there are no checkpoints for the group ID, the resulting map will just be empty. I'm guessing the intention with the new batched method variant is similar--if there are no checkpoints for one or more of the specified group IDs, then each of those group IDs will have an entry in the batched map, but its value will be an empty map. Is that correct, instead of alternatives like there being no entry in the batched map for those group IDs, or there being an entry with a null value, or an exception being thrown, etc.? Cheers, Chris On Tue, Nov 25, 2025 at 9:41 AM Mickael Maison <[email protected]> wrote: > Hi, > > I'd like to start a discussion about KIP-1239: Batch offset > translation in RemoteClusterUtils. > This proposes introducing new methods in > RemoteClusterUtils/MirrorClient to translate the offsets multiple > consumer groups at the same time. > > https://cwiki.apache.org/confluence/x/h4HMFw > > Let me know if you have any feedback. > > Thanks, > Mickael >
