[
https://issues.apache.org/jira/browse/KAFKA-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18062094#comment-18062094
]
Chia-Ping Tsai commented on KAFKA-20035:
----------------------------------------
I realize that our discussion highlights a fundamental semantic gap between
`earliest` and `latest`. The gap is that users often want to read all data
strictly "from this moment forward" (when the application starts). This differs
from `earliest` (which processes all historical data) and `latest` (which skips
to the very end, inevitably dropping data during partition expansion of log
truncation)
I have another idea to address this missing scenario. What if `by_duration` is
evaluated exactly once at consumer startup?
The consumer would capture a static timestamp upon initialization and use it
consistently whenever it needs to seek offsets. This means the consumer will
successfully skip all historical data prior to startup. However, when
encountering a newly extended partition or a truncated log, this static
timestamp will naturally fall before the partition's first available record.
The broker will then correctly return the earliest available offset, ensuring
zero data loss
This static-anchor approach also neatly resolves KAFKA-19236, where the
dynamically calculated timestamp drifts during retries and caused unexpected
behaviour. To make the user's intent explicitly clear, we could even introduce
a dedicated policy named `startup_time` instead of overloading `by_duration=0`
[~dajac][~mjsax] WDYT?
> Prevent data loss during partition expansion by enforcing "earliest" offset
> reset for dynamically added partitions
> ------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-20035
> URL: https://issues.apache.org/jira/browse/KAFKA-20035
> Project: Kafka
> Issue Type: Bug
> Components: clients, consumer, core, group-coordinator
> Reporter: Chia-Ping Tsai
> Assignee: Ken Huang
> Priority: Critical
> Labels: kip
>
> Currently, when a consumer group is configured with {{{}auto.offset.reset =
> latest{}}}, dynamically adding new partitions to a subscribed topic can lead
> to data loss due to a race condition.
> The scenario is as follows:
> # A group subscribes to a topic with {{{}auto.offset.reset = latest{}}}.
> # The topic is expanded (e.g., from 3 to 4 partitions).
> # Producers immediately start writing data to the new partition (Partition
> 3).
> # The Group Coordinator detects the change and assigns Partition 3 to a
> member.
> # The member initializes the partition. Since there is no committed offset,
> it applies the
> # *Result: Any messages written to Partition 3 between step 3 and step 5 are
> skipped and lost.*
> From a user's perspective, {{latest}} should mean "start consuming from the
> point of subscription," not "skip data from newly created infrastructure."
> KIP-1282:
> [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=406619800]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
