slachiewicz opened a new pull request, #310: URL: https://github.com/apache/flink-connector-kafka/pull/310
## What is the purpose of the change `FlinkKafkaInternalProducerITCase.testResetInnerTransactionIfFinalizingTransactionFailed` is flaky ([FLINK-40621](https://issues.apache.org/jira/browse/FLINK-40621)). It sends a record without flushing, then fences that producer with a second one using the same transactional id, and asserts the finalizer throws `ProducerFencedException`. Which exception arrives depends on where the first producer's `ProduceRequest` lands relative to the epoch bump: - The record is accepted first, so the fencing surfaces on the `EndTxn` path as `PRODUCER_FENCED`, and the assertion holds. - The `ProduceRequest` arrives after the bump, so the broker rejects it with `INVALID_PRODUCER_EPOCH` and the finalizer throws `InvalidProducerEpochException`. In kafka-clients 4.2.0 both are siblings under `ApplicationRecoverableException`, neither a subtype of the other, so the second ordering fails the assertion. The reported failure carries the produce-path message, `attempted to produce with an old epoch`. ## Brief change log - `FlinkKafkaInternalProducerITCase`: flush the fenced producer before the second producer starts, so the failure is always discovered on the `EndTxn` path. A comment records why the flush is load-bearing. No production code and no assertion change: widening the assertion to the shared supertype would also be green, but would stop pinning which path failed. ## Verifying this change `mvn -pl flink-connector-kafka -Dtest='FlinkKafkaInternalProducerITCase#testResetInnerTransactionIfFinalizingTransactionFailed' verify` → 2 tests, 0 failures, both parameterizations. That is one local run against a passing ordering, so it does not by itself prove the race is gone; the argument for that is the flush removing the interleaving rather than the run. ## Does this pull request potentially affect one of the following parts? - Dependencies (does it add or upgrade a dependency): no - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no - The serializers: no - The runtime per-record code paths (performance sensitive): no ## Documentation - Does this pull request introduce a new feature? no - If yes, how is the feature documented? not applicable *This change was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
