[
https://issues.apache.org/jira/browse/KAFKA-20547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102959#comment-18102959
]
Nikita Shupletsov commented on KAFKA-20547:
-------------------------------------------
I wonder if it can be related to
https://issues.apache.org/jira/browse/KAFKA-17754
[~bloku] you reproduced it in 3.9.1, right?
it may be the same sequence [~alivshits] showed in his example:
# Transaction T_k commits offsets \{A-partition → 39299}. Its TxnOffsetCommit
times out client-side and is retried; the retry succeeds, T_k commits. The
original request is still in flight.
# ~100ms later Streams opens T_k+1, processes 39299..39317, produces the
commands to C.
# The zombie TxnOffsetCommit from step 1 lands — same producer ID, same epoch,
valid generation — so the coordinator accepts it into the current transaction,
overwriting offset 39318 with the stale 39299.
# T_k+1 commits. Output records are committed (C reads them legitimately) but
the materialized offset is 39299.
# B fails at 39332, restarts, fetches committed offset ≈ 39298/39299, replays
39299..39317 → C sees the commands twice, both in properly committed
transactions.
> Streams produces duplicates with EOS_v2
> ---------------------------------------
>
> Key: KAFKA-20547
> URL: https://issues.apache.org/jira/browse/KAFKA-20547
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 3.9.1
> Reporter: Uladzislau Blok
> Assignee: Nikita Shupletsov
> Priority: Major
> Attachments: Untitled-2026-04-28-1158.excalidraw-1.png
>
>
> Hello All,
> I saw an issue when Kafka Streams processed same input twice resulting in
> duplicated output, what breaks EOS
> See attached diagram describing what went wrong
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
