You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Ritika Reddy (Jira)" <ji...@apache.org> on 2025/09/16 20:24:00 UTC
[jira] [Assigned] (KAFKA-19446) TV2 late marker can violate EOS guarantees.
[ https://issues.apache.org/jira/browse/KAFKA-19446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ritika Reddy reassigned KAFKA-19446:
------------------------------------
Assignee: Ritika Reddy (was: Justine Olshan)
> TV2 late marker can violate EOS guarantees.
> -------------------------------------------
>
> Key: KAFKA-19446
> URL: https://issues.apache.org/jira/browse/KAFKA-19446
> Project: Kafka
> Issue Type: Task
> Affects Versions: 4.0.0, 4.1.0
> Reporter: Justine Olshan
> Assignee: Ritika Reddy
> Priority: Major
>
> One case we missed in KIP-890 is if a late arriving WriteTxnMarkerRequest comes in to a partition for a transaction using TV2.
> Because we write a marker with epoch +1, we send the request with epoch +1. Due to the somewhat relaxed check on epochs at the log layer ([https://github.com/apache/kafka/blob/fd70290633191b6f53a9d4ddb24e3a8b619fcd3f/storage/src/main/java/org/apache/kafka/storage/internals/log/ProducerAppendInfo.java#L211)] , we can actually accept a late arriving request for the previous transaction since the epoch will be the same.
> We should tighten up this check to not allow the same epoch when using TV2. In other words, the marker should always be >= epoch + 1 the current producer state epoch. (The epoch can be greater than +1 if we restart the producer and bump epoch.) We just need a good way to tell if a marker is meant for a TV2 transaction.
> This + 1 works even if we didn't produce records, since the previous marker will update the epoch
--
This message was sent by Atlassian Jira
(v8.20.10#820010)