[ https://issues.apache.org/jira/browse/KAFKA-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286052#comment-17286052 ]
Matthias J. Sax commented on KAFKA-12323: ----------------------------------------- Thanks [~guozhang]. SGTM. – Are we sure that we want to use current wall-clock time as default timestamp for output records of wall-clock time punctuations? I am ok with it, just wanted to double check. Using current stream-time as default timestamp for output records for both punctuation types seems like a sound alternative approach. As it is a regression, I am tagging this a blocker for 2.8.0 and 2.7.2 release. [~abellemare] are you interested picking it up? > Record timestamps not populated in event > ---------------------------------------- > > Key: KAFKA-12323 > URL: https://issues.apache.org/jira/browse/KAFKA-12323 > Project: Kafka > Issue Type: Bug > Components: streams > Affects Versions: 2.7.0 > Reporter: Adam Bellemare > Priority: Major > Attachments: PunctuateTimestampZeroTest.java > > > Upgraded a kafka streams application from 2.6.0 to 2.7.0. Noticed that the > events being produced had a "CreatedAt" timestamp = 0, causing downstream > failures as we depend on those timestamps. Reverting back to 2.6.0/2.6.1 > fixed this issue. This was the only change to the Kafka Streams application. > Consuming the event stream produced by 2.6.0 results in events that, when > consumed using the `kafka-avro-console-consumer` and `--property > print.timestamp=true` result in events prepended with the event times, such > as: > {code:java} > CreateTime:1613072202271 <key> <value> > CreateTime:1613072203412 <key> <value> > CreateTime:1613072205431 <key> <value> > {code} > etc. > However, when those events are produced by the Kafka Streams app using 2.7.0, > we get: > {code:java} > CreateTime:0 <key> <value> > CreateTime:0 <key> <value> > CreateTime:0 <key> <value> > {code} > I don't know if these is a default value somewhere that changed, but this is > actually a blocker for our use-cases as we now need to circumnavigate this > limitation (or roll back to 2.6.1, though there are other issues we must deal > with then). I am not sure which unit tests in the code base to look at to > validate this, but I wanted to log this bug now in case someone else has > already seen this or an open one exists (I didn't see one though). -- This message was sent by Atlassian Jira (v8.3.4#803005)