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 >
