Hi, I'm not very keen on handling null as a sentinel value. Do we do that anywhere else in the Kafka APIs? Did you have a specific use case in mind?
Considering translation is an expensive operation, especially when returning all groups, I'd rather have users to provide a valid Pattern and throw immediately if null is provided. For clarity I added @throw to the javadoc examples. Thanks, Mickael On Wed, Feb 4, 2026 at 6:28 PM Chris Egerton <[email protected]> wrote: > > Hi Mickael, > > Thanks, I like this approach and would be willing to +1 it on a vote > thread. I think it may be useful to make the Pattern nullable and, if null > is passed, return translated offsets for all consumer groups, but I don't > consider that a blocker for the KIP. > > Cheers, > > Chris > > On Wed, Feb 4, 2026, 11:57 Mickael Maison <[email protected]> wrote: > > > Hi Chris, > > > > Thanks for the feedback. > > > > 1. Yes I agree that supporting the "translate all" use case is worth > > considering. > > Instead of adding an additional method, I updated the proposal to > > specify the consumer groups to translate via a regex instead of a > > collection. > > I think the memory footprint would only become an issue with extremely > > large number of committed offsets. > > > > 2. Not applicable anymore with the new API > > > > Thanks, > > Mickael > > > > On Tue, Nov 25, 2025 at 4:03 PM Chris Egerton <[email protected]> > > wrote: > > > > > > 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 > > > > > >
