DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
Discussion thread: here
JIRA: TBD
| Jira | ||||||
|---|---|---|---|---|---|---|
|
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
| Configuration name | Description | Values |
|---|---|---|
group.streams.topology.description.plugin.class | The fully qualified class name of a StreamsGroupTopologyDescriptionPlugin implementation. When not set, the feature is disabled. | Type: |
New Client Configuration
| Configuration name | Description | Values |
|---|---|---|
topology.description.push.enabled | Controls whether the Kafka Streams client sends topology descriptions to the broker when requested. When set to | Type: boolean, Default: true |
...
| Code Block | ||
|---|---|---|
| ||
{ "name": "TopologyDescriptionRequired", "type": "bool", "versions": "N+", "ignorable": true, "default": "false",
"about": "True if the client should send the topology description via StreamsGroupTopologyDescriptionUpdate." } |
...
| Code Block | ||
|---|---|---|
| ||
{
"apiKey": "TBD",
"type": "request",
"listeners": ["broker"],
"name": "StreamsGroupTopologyDescriptionUpdateRequest",
"validVersions": "0",
"flexibleVersions": "0+",
"fields": [
{ "name": "GroupId", "type": "string", "versions": "0+", "entityType": "groupId",
"about": "The streams group identifier." },
{ "name": "MemberId", "type": "string", "versions": "0+",
"about": "The ID of the streams group member sending the push." },
{ "name": "TopologyEpoch", "type": "int32", "versions": "0+",
"about": "The epoch of the topology being described." },
{ "name": "TopologyDescription", "type": "TopologyDescription", "versions": "0+",
"about": "The topology description." }
],
"commonStructs": [
{ "name": "TopologyDescription", "versions": "0+", "fields": [
{ "name": "Subtopologies", "type": "[]Subtopology", "versions": "0+",
"about": "The subtopologies that make up this topology." },
{ "name": "GlobalStores", "type": "[]GlobalStore", "versions": "0+",
"about": "Global state stores used by this topology." }
]},
{ "name": "Subtopology", "versions": "0+", "fields": [
{ "name": "SubtopologyId", "type": "string", "versions": "0+",
"about": "The subtopology identifier, unique within the topology." },
{ "name": "Nodes", "type": "[]TopologyNode", "versions": "0+",
"about": "The processing nodes in this subtopology." }
]},
{ "name": "TopologyNode", "versions": "0+", "fields": [
{ "name": "Name", "type": "string", "versions": "0+",
"about": "The name of this node (e.g., KSTREAM-SOURCE-0000000000)." },
{ "name": "NodeType", "type": "int8", "versions": "0+",
"about": "The type of this node: 1=SOURCE, 2=PROCESSOR, 3=SINK." },
{ "name": "SourceTopics", "type": "[]string", "versions": "0+", "entityType": "topicName",
"about": "The source topics this node reads from. Defined only for source nodes, may be empty if source topics are dynamically determined." },
{ "name": "SinkTopic", "type": "string", "versions": "0+", "entityType": "topicName",
"nullableVersions": "0+", "default": "null",
"about": "The topic this node writes to. Defined only for sink nodes, may be null if sink topic is dynamically determined." },
{ "name": "Stores", "type": "[]string", "versions": "0+",
"about": "The state store names accessed by this node. Defined only for processor nodes." },
{ "name": "Successors", "type": "[]string", "versions": "0+",
"about": "The names of successor nodes in the processing graph. Predecessor relationships are reconstructed from this field on the read side." }
]},
{ "name": "GlobalStore", "versions": "0+", "fields": [
{ "name": "Source", "type": "TopologyNode", "versions": "0+",
"about": "The source node providing data to the global store." },
{ "name": "Processor", "type": "TopologyNode", "versions": "0+",
"about": "The processor node that populates the global store." }
]}
]
} |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
{"name": "IncludeTopologyDescription", "type": "bool", "versions": "N+", "ignorable": true, "default": "false",
"about": "Whether to include the full topology description from the topology description plugin in the response." } |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
{ "name": "TopologyDescription", "type": "TopologyDescription", "versions": "N+",
"nullableVersions": "N+", "ignorable": true, "default": "null",
"about": "The topology description for this group. Null if not available — see TopologyDescriptionStatus for the reason." },
{ "name": "TopologyDescriptionStatus", "type": "int8", "versions": "N+", "ignorable": true, "default": "0",
"about": "The status of the topology description for this group: 0=NOT_REQUESTED (client did not set IncludeTopologyDescription), 1=NOT_STORED (no topology description has been recorded for this group), 2=ERROR (the broker failed to fetch the topology description; check broker logs), 3=AVAILABLE (a topology description is present in the TopologyDescription field). The broker MUST set this field to AVAILABLE whenever it attaches a TopologyDescription." } |
The TopologyDescription common struct mirrors the struct used by StreamsGroupTopologyDescriptionUpdateRequest (same field names and shape). Because The nested struct names are prefixed TopologyDescription to avoid collision with the existing Subtopology struct already defined for the describe response. Because Kafka RPC schemas do not share common structs across message files, the struct is duplicated in StreamsGroupDescribeResponse.json. Setting these fields does not change the ErrorCode on the DescribedGroup: a group with a successful describe but a missing or failed topology fetch still returns ErrorCode=NONE. The TopologyDescriptionStatus field tells the caller why TopologyDescription is null, so that "waiting for first push" (NOT_STORED) can be distinguished from "broker-side fetch failed" (ERROR) without an error-level change to the describe result.
...
A new generic error code is added to the per-group ErrorCode slot:
DELETEGROUP_DELETION_FAILED— the delete operation could not complete; the accompanyingErrorMessagedescribes the underlying cause. The group is not tombstoned, and the caller may retry once the underlying condition is resolved. For streams groups configured with a topology description plugin this is returned whenplugin.deleteTopologyfails; other group types may adopt the same code in the future.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
/**
* A broker-side plugin that stores, forwards, or exposes topology descriptions pushed
* by Kafka Streams clients.
*
* <p>Implementations must be thread-safe. {@link #setTopology} may be called
* concurrently by multiple members of the same group; calls with the same
* {@code (groupId, topologyEpoch)} carry identical data and must be idempotent.
* {@link #deleteTopology} must also be idempotent — it may be called more than once
* for the same {@code groupId}, including when nothing is stored.
*/
@InterfaceStability.Evolving
public interface StreamsGroupTopologyDescriptionPlugin extends Configurable, AutoCloseable {
/**
* Store the topology description for a streams group.
*
* <p>The returned future completes when the topology has been persisted or forwarded.
* Failures must be signalled by completing the future exceptionally — implementations
* must not throw synchronously. The completion exception drives broker-side behaviour:
*
* <ul>
* <li>{@link StreamsTopologyDescriptionPermanentFailureException} — the description will never be accepted
* at this topology epoch (e.g. too large, semantically rejected). The broker
* ratchets {@code LastFailedTopologyEpoch} and stops re-soliciting until the
* epoch advances.</li>
* <li>{@link StreamsTopologyDescriptionTransientFailureException} or any other exception — treated as
* transient. The broker arms or extends the per-group back-off (30 s → 1 h,
* exponential) and re-solicits on a later heartbeat.</li>
* </ul>
*
* In both cases the caller receives error code
* {@code STREAMS_TOPOLOGY_DESCRIPTION_UPDATE_FAILED} with the exception's message in
* {@code ErrorMessage}; the permanent-vs-transient split is broker-internal state.
*/
CompletableFuture<Void> setTopology(String groupId, int topologyEpoch,
StreamsGroupTopologyDescription description);
/**
* Remove any topology description stored for this group. Called when the group is
* deleted or expires. A failure (future completed exceptionally) is reported to the
* caller of {@code DeleteGroups} as {@code DELETEGROUP_DELETION_FAILED} with the exception message
* in the per-group {@code ErrorMessage}, and the broker does not tombstone the group;
* a retry of {@code DeleteGroups} re-invokes this method idempotently. The
* periodic-cleanup path treats a failure identically — the group's tombstone is
* deferred to a future cycle.
*/
CompletableFuture<Void> deleteTopology(String groupId);
/**
* Return the stored topology description for {@code (groupId, topologyEpoch)}, or
* {@code null} if the plugin no longer has the data (e.g. backend wipe). If the future
* completes exceptionally, the broker reports a read error for the group.
*/
CompletableFuture<StreamsGroupTopologyDescription> getTopology(String groupId, int topologyEpoch);
} |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
package org.apache.kafka.coordinator.group.api.streams;
public class StreamsGroupTopologyDescription {
public Collection<Subtopology> subtopologies();
public Collection<GlobalStore> globalStores();
public static final class Subtopology {
public String id();
public Collection<Node> nodes();
}
/**
* A processing node in the topology. Predecessor nodes can be inferred from successor relation.
*/
public sealed interface Node {
String name();
Set<String> successors();
}
public static final class Source implements Node {
public Set<String> topics();
}
public static final class Processor implements Node {
public Set<String> stores();
}
public static final class Sink implements Node {
public Optional<String> topic();
}
public static final class GlobalStore {
public Source source();
public Processor processor();
}
} |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
package org.apache.kafka.coordinator.group.api.streams; import org.apache.kafka.common.errors.ApiException; import org.apache.kafka.common.annotation.InterfaceStability; /** Signals that the topology description for the current epoch will never be accepted (e.g. too large, semantically rejected). */ @InterfaceStability.Evolving public class StreamsTopologyDescriptionPermanentFailureException extends ApiException { public StreamsTopologyDescriptionPermanentFailureException(String message) { super(message); } public StreamsTopologyDescriptionPermanentFailureException(String message, Throwable cause) { super(message, cause); } } /** Signals a transient backend failure; the broker re-solicits on a later heartbeat. Plugins that throw any other exception are treated identically. */ @InterfaceStability.Evolving public class StreamsTopologyDescriptionTransientFailureException extends ApiException { public StreamsTopologyDescriptionTransientFailureException(String message) { super(message); } public StreamsTopologyDescriptionTransientFailureException(String message, Throwable cause) { super(message, cause); } } |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
{ "name": "StoredTopologyEpoch", "versions": "0+", "taggedVersions": "0+", "tag": 3,
"default": -1, "type": "int32",
"about": "The topology epoch whose description is currently stored in the topology description plugin, or -1 if none is stored." },
{ "name": "LastFailedTopologyEpoch", "versions": "0+", "taggedVersions": "0+", "tag": 4,
"default": -1, "type": "int32",
"about": "The topology epoch whose description push the plugin permanently rejected (TooLargesignalled /by InvalidRequestStreamsTopologyDescriptionPermanentFailureException), or -1 if none. Heartbeat-path solicitation is suppressed while this equals the current topology epoch, to avoid hot-looping." } |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
package org.apache.kafka.clients.admin;
public class StreamsGroupTopologyDescription {
public Collection<Subtopology> subtopologies();
public Collection<GlobalStore> globalStores();
public static final class Subtopology {
public String id();
public Collection<Node> nodes();
}
public interface Node {
String name();
/** Direct predecessor nodes. */
Set<String> predecessors();
/** Direct successor nodes. */
Set<String> successors();
}
public static final class Source implements Node {
public Set<String> topics();
}
public static final class Processor implements Node {
public Set<String> stores();
}
public static final class Sink implements Node {
public Optional<String> topic();
}
public static final class GlobalStore {
public Source source();
public Processor processor();
}
} |
...
The plugin is instantiated at broker startup if
group.streams.topology.description.plugin.classis configured. A broker without a plugin returnsUNSUPPORTED_VERSIONforStreamsGroupTopologyDescriptionUpdateand never setsTopologyDescriptionRequired, so the RPC is only sent against a plugin-configured broker.After a successful
StreamsGroupHeartbeat, the broker decides whether to setTopologyDescriptionRequired=truepurely from the group's persisted state — no plugin RPC is involved. Members withSTALE_TOPOLOGYstatus are skipped. For all other members the broker sets the flag iffStoredTopologyEpoch != currentTopologyEpochANDLastFailedTopologyEpoch != currentTopologyEpochAND no per-group back-off is in its window. The back-off is in-memory state (keyed bygroupId, carryingtopologyEpoch+nextAttemptMs) that arms or extends every time the flag is set and additionally on a transientsetTopologyfailure; consecutive arms double the window from 30 s up to 1 h. It clears on a successful push, on a permanent failure (whereLastFailedTopologyEpochratchets), and implicitly on any topology-epoch advance. The same mechanism covers unresponsive plugins and clients that never push (for example, withtopology.description.push.enabled=false).On
StreamsGroupTopologyDescriptionUpdate, the broker checks theREADACL on the group and that a plugin is configured, then validates theMemberId: an emptyMemberIdis rejected withINVALID_REQUEST, a non-existing streams group withGROUP_ID_NOT_FOUND, and aMemberIdnot matching any current member withUNKNOWN_MEMBER_ID. The broker enforces no size limit; the plugin decides what it is willing to store. The broker then callssetTopologyon the plugin. On success it writes a metadata record settingStoredTopologyEpoch = pushedEpochand the response carriesNONE. OnStreamsTopologyDescriptionPermanentFailureExceptionit writesLastFailedTopologyEpoch = pushedEpochso subsequent heartbeats at the same epoch do not re-solicit. OnStreamsTopologyDescriptionTransientFailureExceptionor any other exception it writes no metadata record, arms the per-group back-off, and the next heartbeat re-solicits once the window elapses. In both failure cases the response carriesSTREAMS_TOPOLOGY_DESCRIPTION_UPDATE_FAILEDwith the plugin's exception message inErrorMessage; the permanent-vs-transient split is broker-internal state. If the plugin call succeeds but the metadata-record write fails, the next heartbeat sees the drift, re-solicits, and the idempotent re-push closes the gap.On
DeleteGroups, the broker callsdeleteTopologyon the plugin before writing the group tombstone, for each requested streams group withStoredTopologyEpoch != -1. On plugin success the group is tombstoned and the per-groupErrorCodeisNONE. On plugin failure the group is not tombstoned and the per-groupErrorCodeis set toDELETEGROUP_DELETION_FAILEDwith the plugin's exception message inErrorMessage(also logged at WARN); the operator retries the request once the plugin recovers, or unsets the plugin config to bypass it. Other groups in the same batch are unaffected — the failure is reported per group. This ordering matches the natural-expiration cleanup below, which also defers tombstoning untilplugin.deleteTopologysucceeds.- On
StreamsGroupDescribewithIncludeTopologyDescription=true, the broker callsgetTopologyon the plugin only whenStoredTopologyEpoch == currentTopologyEpochfor that group; otherwise it reportsNOT_STOREDwithout making a plugin call. Calls across groups run in parallel. Authorization is unchanged — the existingDESCRIBEACL on the GROUP resource covers the topology description.DescribedGroup.ErrorCodeis never modified by topology-related outcomes; theTopologyDescriptionStatusfield carries the reason whenTopologyDescriptionis null (NOT_REQUESTED,NOT_STORED, orERROR; the last is also logged at WARN). With no plugin configured the broker returnsNOT_STORED. AgetTopologycall returningnull(plugin-side data loss) surfaces asNOT_STOREDand is logged at WARN; subsequent describes keep returningNOT_STOREDuntil the topology epoch advances or an operator clears plugin state. - When a plugin is configured, the broker runs a periodic topology-description cleanup every
offsets.retention.check.interval.ms. Each fire fans out a read-only query across the broker's hosted__consumer_offsetspartitions to identify streams groups eligible for cleanup:isEmpty && allOffsetsExpired && StoredTopologyEpoch != -1. This is the same eligibility predicate the shard's offset-expiration sweep uses to delete consumer/share groups, with the additionalStoredTopologyEpoch != -1filter. For each eligible group, the broker callsplugin.deleteTopology(groupId)and, on success, writes a metadata record settingStoredTopologyEpoch = -1. Plugin failures leave the field set; the same group is retried on the next cycle. OnceStoredTopologyEpoch = -1, the shard's offset-expiration sweep tombstones the (now flag-cleared) group on a subsequent cycle. When no plugin is configured, the periodic cleanup does not run and the shard's offset-expiration sweep expires streams groups normally, ignoringStoredTopologyEpoch; operators that disable a previously-configured plugin are responsible for cleaning up plugin-side state out-of-band.
...
DeleteGroupsRequest and DeleteGroupsResponse are bumped to version 3, which adds a per-group ErrorMessage field on the response and introduces the new DELETEGROUP_DELETION_FAILED error code. Older admin clients negotiate version 2 and never see the new field; they continue to receive only the per-group ErrorCode. DeleteGroups can newly fail on streams groups when a topology description plugin is configured and its deleteTopology call fails. Brokers without a configured plugin keep today's behaviour. Older clients that do receive DELETEGROUP_DELETION_FAILED (because they understand version 3 but predate this KIP's error-code addition) decode the code as UNKNOWN_SERVER_ERROR via the standard forward-compatibility fallback in Errors.forCode; the group is still not tombstoned, so an idempotent retry of DeleteGroups converges once the plugin recovers. No client-side change is required.
...
StreamsGroupTopologyDescriptionUpdateRequestTest(new) — push happy path;StreamsTopologyDescriptionPermanentFailureException(ratchetsLastFailedTopologyEpoch) andStreamsTopologyDescriptionTransientFailureException(arms back-off) both surface asSTREAMS_TOPOLOGY_DESCRIPTION_UPDATE_FAILEDwith the cause inErrorMessage; heartbeat-flag gating; member/group/MemberIdfencing; explicitDeleteGroupsplugin-success path (tombstone written) and plugin-failure path (DELETEGROUP_DELETION_FAILEDreturned withErrorMessage, group not tombstoned, retry converges after plugin recovery).StreamsGroupTopologyDescriptionUpdateNoPluginRequestTest(new) — broker without plugin: pushes rejected, flag never set, describe returnsNOT_STORED.AuthorizerIntegrationTest—READACL on the GROUP resource for the new RPC.
...