[
https://issues.apache.org/jira/browse/KAFKA-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286016#comment-17286016
]
Guozhang Wang commented on KAFKA-12323:
---------------------------------------
I checked the source code between 2.6 and trunk, and I think there's indeed a
regression: for old API, the behavior is not actually "For timestamp, the dummy
value is `0L`." Instead, it would just keep the processor context passed in
through the punctuator, and that would carry the timestamp of either stream
time or system time depending on the punctuation type. What's worse, is that
even if using the new API this regression seems still persist.
I think we should fix `StreamTask.punctuate` that when calling
`updateProcessorContext`, we should create a recordContext with the timestamp
passed into it instead of passing null.
> 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)
