...

Clients require no changes. They continue to issue EndTxnRequest as before. With brokers that support this KIP, leaders apply version-aware validation: the legacy rule for TV0/TV1 and the stricter rule for versions greater than or equal to TV2 . This ensures stronger exactly-once guarantees without altering client behavior.

...

• TV0 / TV1 (value = 0 or 1) →                      →   markerEpoch >= currentProducerEpoch (legacy validation)

• TV2 and future TV's (value >= 2)                 →     → markerEpoch > currentProducerEpoch (strict validation)

...

If a coordinator supports version 2 but a partition leader only supports version 1, the coordinator will automatically fall back to sending a version 1 request. This ensures smooth interoperability and maintains backward compatibility.

New Transaction Versions

Future transaction versions will also be subjected to a strict validation by default. If a newer version ever changes or removes the epoch bump behavior introduced in TV2, the broker logic should be updated accordingly. Applying strict validation to all versions ≥ TV2 keeps the behavior forward compatible and ensures the issue remains permanently resolved.

Test Plan

Integration testing will be done to test the various writeTxnMarker request scenarios like testing behavior when stale markers arrive with both TV1 and TV2.

...