@authorjapps There was a bug in the seekTo feature . In situations where there are multiple partitions on the topic and some of the partitions do not have a valid offset corresponding the timestamp to seek to, the seek operation will give an NPE.

Can you review the fix?

@authorjapps There was a bug in the seekTo feature . In situations where there are multiple partitions on the topic and some of the partitions do not have a valid offset corresponding the timestamp to seek to, the seek operation will give an NPE.

Can you review the fix?

Got you @a1shadows . That scenario causing NPE.
Is there anyway to reproduce this in a single node Kafka in our docker setup?

e.g.
by creating a topic with two or three partitions, then sending records to 1 and 3 based on their key, then not sending any record to 2.
Then try to consume with seekTimestamp, it should fail with NPE

Then with the fix, it should pass as expected(without NPE)

e.g.
by creating a topic with two or three partitions, then sending records to 1 and 3 based on their key, then not sending any record to 2.
Then try to consume with seekTimestamp, it should fail with NPE

Then with the fix, it should pass as expected(without NPE)

@authorjapps I'll look into this

@authorjapps I've added a multi partition topic test to the CI. For this, I added an init container to the docker compose file, since by default the cp-kafka docker image does not accept num.partitions as an env variable for auto created topics. I ran it locally and it ran fine. However, for the CI the docker compose files are picked from the master branch so can't get a proper test on here

Do you have anything in mind for this? Can we run the CI using the docker compose files on the branch we are trying to merge?