...

Internally, the tool will first use `DescribeProducers` to validate that there is an open transaction beginning at that offset and collect the ProducerId and ProducerEpoch.

For compatibility with older brokers, we also support the ability to directly specify additional parameters. Although we cannot use the new APIs in this case to validate the state, this is still better than nothing for users who have hit this problem. In this case, users have no choice but to do the analysis themselves by dumping the log of a suspected topic partition. In this case, we the command takes the following arguments:

• --producer-id
• --producer-epoch
• --coordinator-epoch

As described above, the partition leader will allow an administrative abort only if the producer epoch matches the latest value and there is an open transaction beginning at the indicated offset. Users are required to use the --describe command to find this information.beginning at the indicated offset. Users are required to use the --describe command to find this information.

> kafka-transactions.sh --abort \
  --topic foo  \
  --partition 0  \
  --start-offset 550 \
  --bootstrap-server localhost:9092

> kafka-transactions.sh --abort \
  --topic foo  \
  --partition 0  \
  --start-offset 550producer-id 134132 \
  --producer-epoch 23 \
  --coordinator-epoch 15 \
  --bootstrap-server localhost:9092

Note that we are not providing an option to commit a transaction through this API.

...

This proposal adds new tools to facilitate the recovery of hanging transactions. These tools will not generally be compatible with older versions since they rely on new APIs. However, the --abort command described above will be compatible with older brokers.

Rejected Alternatives

If there were a simple and safe way to automatically detect which transactions were left hanging, then an automatic recovery option might be preferable. We have considered two options: 

...