Thank you for the feedback Justine. Yes, I can expand on the KIP what the 
behavior is when we return INVALID_TIMESTAMP.


On 5/30/23, 1:34 PM, "Justine Olshan" <jols...@confluent.io.inva 
<mailto:jols...@confluent.io.inva>LID> wrote:


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.






Hi Mehari,


This is an interesting KIP! I've seen my fair share of issues due to future
timestamps, so this is definitely an area that could be improved.


I noticed in the compatibility section it says:
> There are no changes to public interfaces that will impact clients.
However, this change is considered breaking, as messages with future
timestamps that were previously accepted by the broker will now be rejected.


It seems that INVALID_TIMESTAMP is not retriable so it will fail the batch.
I think that if we expect to handle this case just as we do for the already
existing invalid_timestamp error, we should include some information on how
that is handled in the KIP.


Thanks,
Justine




On Tue, May 30, 2023 at 1:07 PM Beyene, Mehari <meh...@amazon.com.inva 
<mailto:meh...@amazon.com.inva>lid>
wrote:


> Hi Everyone,
>
> I would like to start a discussion on KIP-937: Improve Message Timestamp
> Validation (
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-937%3A+Improve+Message+Timestamp+Validation
>  
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-937%3A+Improve+Message+Timestamp+Validation>
> ).
> This is a small KIP that aims to tighten the current validation logic of a
> message timestamp.
>
> Thanks,
> Mehari
>



Reply via email to