DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
Depend on VerificationStateEntry.supportsEpochBump(): This method indicates whether an epoch bump has occurred, and in theory could help leaders distinguish between TV1 and TV2. However, its state is cleared after the first record batch is written. This leaves a protection gap for late or duplicate markers, which may still arrive after the state has been reset. Because it is not reliable as a persistent signal of the transaction version, it cannot help in enforcing stricter validation.
Store transaction version in producer state entry: Enables explicit version tracking but adds storage overhead and requires bumping the record format, increasing complexity for little gain.
- Use a tagged field in the WriteTxnMarkersRequest : The tagged field approach provides a simple way to add a new field while maintaining backward compatibility. However, because version negotiation already occurs through the ApiVersionsRequest, backward compatibility is equally preserved with an API version bump. Kafka generally prefers version bumps for API evolution, as they make protocol changes explicit, allow the removal of deprecated versions over time, and provide clear visibility into which request versions clients and brokers are using.