Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

Uhmm, I'm not willing to leave my address (which is required in the CLA agreement signing form) just for doc clarification 🤦

I'll be glad if the change gets into mainline by merging this PR or by opening a new one from existing contributors

thanks, agree some better docs here would be good (though I'd choose different wording).

i'll address this when I make changes for KIP-320, which confuses things even further by committing the leader epoch associated with the message before the committed offset...

Hi, it's me again.

So, as you supposed, KIP-320 changes really messed things up. Code that used StoreOffset, just silently broke when we upgraded Confluent.Kafka from 2.0.2 to 2.1.1.

The reason is that the leaderEpoch parameter isn't required by the TopicPartitionOffset ctor but at the same time without it StoreOffset doesn't do anything without throwing any exception or logging any errors.

I was able to figure it out when switched debug logs on and saw a bunch of [thrd:main]: Topic <topic_name> [<partition_number>]: stored offset INVALID (leader epoch -1), committed offset 873041 (leader epoch -1): not including in commit messages.

I think it should be at least documented and/or marked as breaking in release notes, though I'm not sure what the real solution should be.

Should I post a separate issue?