KIP-516 — topic identifiers

Status: partial — see the KIP index. Earlier planning documents listed this KIP as implemented; the 2026-07-19 source sweep corrected it.

What's missing

Broker-side wire propagation. The plumbing that would carry a topic's UUID to the wire exists (crates/kaas-k8s/src/topic_watcher.rs caches Status.TopicID per topic), but the production topic watch (run_topic_watch in crates/kaas-k8s/src/kube_watchers.rs) inserts registry entries with the all-zero sentinel — so Metadata v10+ serves nil topic IDs for every topic, and clients fall back to name-based lookups. CreateTopics v7+ returning the UUID in its response is likewise open.

What the KIP changes in Apache Kafka

KIP-516 gives every topic an immutable UUID alongside its name, closing the delete-and-recreate ambiguity: a fetcher or metadata cache holding the old topic's ID can tell it apart from the re-created namesake. Requests and responses grew topic-ID fields from Metadata v10 / Fetch v13 onward.

What kaas has

The identity half, operator-side and durable:

• The KafkaTopic controller (crates/kaas-operator-controllers/src/kafkatopic_controller.rs) mints a cryptographically random v4 UUID into Status.TopicID on first reconcile and never rotates it — a re-created topic gets a distinct ID, exactly Apache's contract. kubectl get kafkatopic -o yaml shows it.
• The broker's topic registry (crates/kaas-broker/src/topic_registry.rs) carries a 16-byte topic_id per topic and the Metadata handler encodes it — today always the all-zero value, which the protocol defines as the "no topic ID" sentinel, so clients degrade gracefully rather than misbehave.

Because kaas serves Fetch v4–v12 (matrix) — below the v13 topic-ID cutover — the Fetch path never needs an ID, which is why the gap is invisible to normal produce/consume traffic.

How the partial state is verified

Operator-side minting and non-rotation are covered by the kafkatopic controller's reconcile tests; the wire-side sentinel is pinned by the Metadata handler's unit tests (crates/kaas-broker/src/handlers/metadata.rs). The gap itself is explicit: every TopicMeta insertion in bins/kaas/src/main.rs writes topic_id: [0u8; 16].