[
https://issues.apache.org/jira/browse/KAFKA-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242571#comment-17242571
]
Matthias J. Sax commented on KAFKA-10688:
-----------------------------------------
1) As the topic is empty, it does not really matter, both "earliest" and
"latest" would result in offset zero.
2b) Seems there might one corner case (maybe we could ignore this corner case
though): the application for whatever reason did not commit offset but there
was also no truncation – for this case, it seems ok to just reset to earliest?
Btw: IIRC, we only set the consumer config to `none` iff there are topic with
different policies atm. If there is no topic specific config (ie, only the
global config) or if all topic specific configs and the global config are the
same, we just pass it into the consumer.
What I am wondering though is: why don't we just try to tackle KAFKA-3370
directly? Seems to be a good improvement.
> Handle accidental truncation of repartition topics as exceptional failure
> -------------------------------------------------------------------------
>
> Key: KAFKA-10688
> URL: https://issues.apache.org/jira/browse/KAFKA-10688
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Guozhang Wang
> Assignee: Guozhang Wang
> Priority: Major
>
> Today we always handle InvalidOffsetException from the main consumer by the
> resetting policy assuming they are for source topics. But repartition topics
> are also source topics and should never be truncated and hence cause
> InvalidOffsetException.
> We should differentiate these repartition topics from external source topics
> and treat the InvalidOffsetException from repartition topics as fatal and
> close the whole application.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
