[
https://issues.apache.org/jira/browse/KAFKA-20876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101481#comment-18101481
]
Matthias J. Sax commented on KAFKA-20876:
-----------------------------------------
[~lh0156] – it seems you are opening a lot of PRs across the board. – While we
appreciate AI assistant coding, it startd to raise the question if you as a
contributor (who is ultimately responsible for the PRs) really understand all
these PRs? We don't want to get into an "AI slop" battle – reviewing PRs is
very time consuming and we are already overloaded with review request. Getting
more PRs of potentially low quality would not be helpful for the project (low
quality PR only consumer time that is missing elsewhere, overall doing more
harm than good). I did not look into your PRs, so maybe they are all indeed of
good quality – I just don't know – but please ensure to avoid AI slop. Thanks a
lot.
Also, this ticket is assigned to [~alau], and it's considered rude to pickup
already assigned tickets (and I did see you did the same for other tickets).
Please make sure that you first get a ticket assigned, by asking the current
owner if they are willing to transfer it to you (if there is no response by the
current owner within a week, feel free to re-assign, too). Thanks a lot for
being part of the community and your contributions. Let's keep playing by the
rules :)
> Windowed restore optimisation gives up when `endOffset-1` is a transaction
> control record
> -----------------------------------------------------------------------------------------
>
> Key: KAFKA-20876
> URL: https://issues.apache.org/jira/browse/KAFKA-20876
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 4.4.0
> Reporter: Alan Lau
> Assignee: Alan Lau
> Priority: Blocker
>
> When restoring a windowed store with no checkpoint, {{StoreChangelogReader}}
> seeks to {{latestTimestamp - retentionPeriod}} instead of {{{}log-start{}}},
> since data older than the retention is discarded on write. It learns
> {{latestTimestamp}} by seeking to {{endOffset - 1}} and polling once in
> {{{}seekNewPartitions{}}}; an empty poll falls back to
> {{{}seekToBeginning{}}}.
> On a 4.3 EOS-v2 soak, {{endOffset - 1}} returned no record on 195 of 195
> probes. Dumping the segment confirms the last batch is a transaction control
> record (isControl: true, count: 1, size: 78), and the pattern recurs
> throughout — every transaction ends with a marker occupying an offset that is
> never delivered to a consumer. The poll therefore returns nothing and the
> optimisation is abandoned, leaving the restore at log-start with no margin
> against retention.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
