Hi Gabriel, Sounds like a bug to me (although we didn't document anywhere about the generation id will always start from 0). You can file a jira and we can discuss it there.
Thank you. Luke On Fri, Jun 10, 2022 at 9:35 PM Gabriel Giussi <gabrielgiu...@gmail.com> wrote: > I did the following test that allowed me to introduce a duplicate message > in the output topic. > > > 1. Client A starts the consumer and the producer and holds a reference to > the current groupMetadata wich has generation.id -1 since the consumer > didn't join the group yet > 2. Client A joins the group and gets assigned partition 0 and 1 > 3. Client A polls a message with offset X from partition 1, produces to > output topic and enters a long gc pause (before calling > sendOffsetsToTransation) > 4. Client B starts the consumer and the producer, also getting a reference > to groupMetadata with generation.id -1 > 5. Client B joins the group and gets assigned partition 1 > 6. Client B polls a message with offset X from partition 1, produces to > output topic, sends offset with generation.id -1, and commits > successfully. > 7. Client A comes back and send offsets with generation.id -1 and commits > successfully > > I did this test because it wasn't so clear for me at which moment I had to > get the meta and this seems to be a bug to me, since it shouldn't allow > sending offsets with generation.id -1. > I know that the right way to do it is to ask for the meta after each poll, > in that way we always have the generation.id corresponding to the moment > where the messages were polled from the broker, but it would be nice to > have an error if we send generation.id -1. WDYT? > > Thanks. >
