firecow commented on PR #20868:
URL: https://github.com/apache/kafka/pull/20868#issuecomment-3990186427
We're hitting an issue with this change during a rolling upgrade from 4.1.1
to 4.2.0 in a KRaft cluster (combined mode).
When a 4.2.0 broker's transaction coordinator sends WriteTxnMarkers to a
broker still on 4.1.1, it uses v2 of the API. The 4.1.1 broker only supports v1
(validVersions: "1") and rejects it:
org.apache.kafka.common.errors.UnsupportedVersionException: Received
request for api with key 27 (WriteTxnMarkers) and unsupported version 2
This fires continuously (~500/sec) for the entire mixed-version window,
closing sockets and preventing transaction markers from being written. It stops
immediately once the receiving broker is also upgraded to 4.2.0.
The PR states the TransactionVersion field is ignorable and will be
omitted when serialized at v1, which is correct — but the version negotiation
never falls back to v1 in the first place. The 4.2.0 broker sends v2 despite
the target
advertising only v1 in its ApiVersions response.
Cluster state:
- 3-node KRaft, process.roles=[broker, controller]
- metadata.version: 4.0-IV3 (feature level 25)
- transaction.version: 2
- Broker receiving the requests: metadata.version maxSupportedVersion=27
(confirming 4.1.1)
- Broker sending the requests: just restarted on 4.2.0
Rolling upgrades have always worked one broker at a time for us across
prior versions. This is a regression in 4.2.0.
--
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]