Release support matrix

This page says which clients, broker builds, security modes, storage modes and deployments have evidence, and how current that evidence is. Every row links the run, pull request or issue comment that holds the evidence, and names the revision that the evidence is for. A row without current evidence says so. It does not borrow evidence from another revision.

The page is the support-matrix half of #1400. Candidate qualification and the release-blocker list are #1401. The KIP-level claims are in the KIP matrix, and the tool classes that cannot work are in Ecosystem support.

How to read this page

Candidate revision: none

No release candidate is frozen yet. #1401 freezes it, with the procedure and gates in Release candidate qualification. Until then, no row can be candidate, and every passing result below is historical: it is true of the revision that it names, and it says nothing about a later build. A draft manifest for v1.0.8 waits for maintainer review, and it does not freeze anything.

aspect check-support-matrix reads this page. It fails when a row has another status, when a row has no evidence link, when an executed row names no revision, when an untested row links no issue, and when a row is candidate but does not name the candidate revision. CI runs it in the checks job.

Reference runs

The rows cite these runs. This page is current as of 2026-10-25. A container suite builds the broker from the source at its revision, so the image digest names the delivered image of that revision. It does not prove that the suite ran those bytes. #1401 binds the candidate evidence to the delivered bytes.

Broker builds

Clients

The Kafka image column of the KIP matrix says which KIP each image covers. The rows below say when each client last ran.

Security modes

Storage modes

Deployment configurations

Upgrades and rollback

Upgrade paths

Deploy is the procedure. The rules come from Persisted formats.

• 1.x to 1.y. Roll one node at a time. A 1.y broker reads everything that an earlier 1.x broker wrote.
• 0.x to 1.x. This is not a roll. Run krabka-format on every node and restore the topic data from a backup.
• A new persisted format. The new build keeps writing the old format until you finalize the feature level that introduces it. Roll every node first, then finalize with kafka-features.

Rollback restrictions

• Before finalization, you can roll back to any earlier 1.x build, because nothing on disk uses the new format.
• After finalization, a rollback follows Kafka’s downgrade rules for that feature. For metadata.version, krabka implements the KIP-1155 snapshot path. A build that does not support the finalized level cannot join.
• krabka.version. Do not finalize level 1 while the cluster has a JVM Kafka node. A JVM node supports only level 0, and a level above 0 crashes a JVM standby controller. The controller refuses a level that a registered node does not support.
• Tiered DeleteRecords during a roll. Do not run DeleteRecords on a tiered topic while the roll is in progress, until every broker has the fix for #1481. Deploy gives the reason.
• 0.x data has no promise. A 1.x broker does not read it.

#1396 exercised the first two on release images: a rollback to v1.0.5 before finalization, and a refused one after it. The other rules are the documented contract.

Known limitations

These come from the evidence records of milestones 24 to 29. Each item links its source. An item stays here until a linked change removes it.

Open defects

• COORDINATOR_NOT_AVAILABLE under max-rate RF3 load. #1410 fixed two follower-fetch causes, and #1457 stopped segment deletion from stalling appends and follower reads. The storage-stall candidate needs a benchmark-host rerun, which is scheduled with the 1.1 release qualification. #1352 is open.
• A refused rollback can change bytes, intermittently. In two soak_contract runs, the rollback target, v1.0.5 and then v1.0.6, changed the metadata log, the high watermark, leader-epoch-checkpoint and quorum-state while it refused a finalized metadata.version 33. Its startup check missed a level above a lagging high-watermark file. The fix is on main, and a rollback to v1.0.8 or an earlier release still has the window. Release blocker F5 records it.

Fixed since the 2026-10-18 version of this page, and passed at v1.0.8 (3831a25d) but not on a candidate: #1448, a tiered Fetch in the remote band with no response (#1538), and #1442, a killed broker that restarted inside its heartbeat session and kept its partitions (#1553).

Kafka behavior differences

• RE2J consumer-group regexes. Rust regex’s compiled-size limit refuses some nested counts that RE2J 1.8 accepts, such as (a{1000}){1000}. A repetition with no argument is refused with Rust’s message, not RE2J’s. A surrogate escape such as \x{D800} is refused. The “Unresolved” section of #1407 lists them.
• Java regexes in ssl.principal.mapping.rules, Kerberos auth_to_local and KIP-714 match. For a group that only matches the empty string, such as ()*\1, krabka keeps the group where Java’s GroupCurly drops it. Java splits an emoji’s UTF-16 pair in replaceAll("x*"), and a Rust String cannot hold that. #1480 and #1482.
• ShareFetch quotas. ShareFetch charges its active handler time, where the consumer Fetch path charges wall time. A share fetch’s tiered read does not check the fetch quota or the remote wait. Kafka’s KIP-956 throttle-time and quota sensors are not published. #1412 and #1486.
• Authentication. Handler and mute time does not count toward idle expiry. PLAIN compares raw bytes where Kafka decodes lossy UTF-8. A SCRAM proof of the wrong length gets error 58 where Kafka drops the connection. #1390 comment.
• Connection caps. krabka closes a connection over max.connections. Kafka’s acceptor waits for a slot. #1391 comment.
• Dynamic listeners. A TLS listener added without a broker-wide TLS config is not opened. An added listener is not registered with the controller, as in Kafka. #1474.
• The KIP-matrix notes list the remaining per-KIP differences. Read the KIP matrix for the KIP that you depend on.

Evidence gaps

• netem slow followers have run only in the five-minute self-check. The nightly netem job runs bench/soak/self-check-netem.yaml on a GitHub-hosted runner, and its first run passed (job 118454690131). The 72-hour run is the first to repeat the fault under sustained load. #1551.
• Diskless under sustained load has one local self-check and no CI or 72-hour run. #1551.
• read_committed across local eviction on a live cluster, and RF3 consumer-group coordinator failover, have no harness. #1388 comment.
• Performance on the benchmark host after #1438 and #1457 has not run. The RF3 regression budgets ran on a 32-core cloud worker instead, at fd007630; Performance budget results has them. Capacity lists what is measured and where.

Operator findings

No independent operator has installed, migrated or recovered a cluster yet. #1398 defines the two pilots in Pilot acceptance plans, and they wait on its human actions: naming the operators, access and consent. #1399 records an AI agent’s dry run of the runbooks. It is not an operator finding, and every defect it found is fixed on main. This section stays empty until #1399 publishes consented results.

Evidence needed before release

The runs in items 3 to 7 are scheduled with the 1.1 release qualification.

1. Freeze the candidate revision and image digest (#1401), then rerun every historical row on it.
2. One full-matrix run in which every container group passes on the candidate. It passed at v1.0.8 (3831a25d) and in the nightlies up to 782f5b50.
3. The 72-hour RF3 soak, including the diskless and netem faults (#1551), and a pass of the four-hour soak on the candidate. The four-hour soak passed at v1.0.8 and in every nightly from 10-21 to 10-24.
4. A pass of upgrade · previous release on the candidate. It passed at v1.0.8 from v1.0.7. The loaded upgrade and rollback passed at f5c683d9 from and to v1.0.5 (#1396), and must pass on release images and on the candidate.
5. A green secured disaster-recovery drill on a release image or the candidate (#1397). It passed on the main image of 7301120. All eight qualification gates must also pass for a 1.x broker; the preflight at f5c683d9 passed three.
6. Runs of the RF3 regression budgets under rf3-regression-v3 on the candidate, and benchmark-host runs of the preallocate=true workload (#1395, #1370).
7. Operator pilots or labeled independent acceptance runs (#1398, #1399).
8. A disposition for each open defect under Known limitations, and a green main gate again.

Keeping this page current

Change a row only with a link to the run that changes it. When a run fails, set the row to failing and link the failed run. Do not keep an older pass in its place. When #1401 freezes the candidate, set the candidate revision above. Then move each row to candidate only after its check passes on that revision.