Skip to content

[GSoC 2026] Kafka Streams Runner — translation framework + Impulse translator #38616

Closed

Description

@junaiddshaukat

Tracking issue: #18479
Depends on: #38465 (skeleton, merged via #38534)

Summary

Second sub-issue under the Kafka Streams Runner GSoC 2026 project. The
skeleton from #38465 currently throws UnsupportedOperationException
for every transform URN. This issue adds:

  1. A URN-dispatch framework in KafkaStreamsPipelineTranslator (a
    Map<String, TransformTranslator> populated at construction time,
    walked via QueryablePipeline in topological order — same shape as
    FlinkStreamingPortablePipelineTranslator).
  2. The first concrete translator: Impulse
    (beam:transform:impulse:v1). Per the design doc §4.1, this uses a
    dedicated bootstrap topic (e.g. __beam_impulse) so Kafka Streams
    has a real source to consume from, emits one empty byte[] element,
    records in a state store that it has already fired, and advances
    the watermark to BoundedWindow.TIMESTAMP_MAX_VALUE.
  3. The translation context starts holding the Kafka Streams Topology
    being built and the Map<String, String> from PCollection ID to
    processor node name.

After this issue, an Impulse-only pipeline translates and starts a
Kafka Streams topology. Pipelines containing any other URN still fail
fast with No translator registered for URN ... — the message format
unchanged from #38465.

Design doc reference

Portable Kafka Streams Runner for Apache Beam — design doc §4.1, §11.5.

Scope

  • KafkaStreamsTranslationContext: hold Topology, plus
    Map<String, String> pcollectionIdToProcessorName and accessors.
  • KafkaStreamsPipelineTranslator: Map<String, TransformTranslator>
    populated at construction; walk via QueryablePipeline /
    topological order.
  • TransformTranslator interface (single method
    translate(PTransformNode, RunnerApi.Pipeline, KafkaStreamsTranslationContext)).
  • translation/ImpulseTranslator implementing the dedicated-topic
    pattern from design doc §4.1.
  • Bootstrap-topic creation hook (auto-create via AdminClient or
    require pre-created — open question 12.1; pick one with note).
  • Wire KafkaStreamsPipelineRunner.run to actually call
    KafkaStreams.start() on the built topology (instead of
    throwing). Returns a PortablePipelineResult that tracks the
    KafkaStreams instance state.

Acceptance criteria

Out of scope (deferred to follow-up sub-issues)

  • ExecutableStage / stateless ParDo (next sub-issue).
  • GroupByKey, Combine, Window assignment, Flatten.
  • Watermark manager (per Jan: "watermark manager comes last when GBK
    forces it").
  • Splittable DoFn.

Reference implementation

  • runners/flink/2.0/src/main/java/.../FlinkStreamingPortablePipelineTranslator.java
    — URN dispatch map pattern.
  • runners/flink/2.0/src/main/java/.../translation/.../ImpulseSourceFunction.java
    (and surrounding wiring) for the Flink-side analog. Kafka Streams
    needs a different approach because KS requires a real input topic.

cc @je-ik

Activity

  1. durgaprasadml commented on May 30, 2026

    @durgaprasadml
    Contributor

    Hi @junaiddshaukat, I’m interested in working on this issue and have started studying the existing Kafka Streams runner skeleton merged in #38534 along with the follow-up design discussion.

    I’ll first sync with the latest integration branch and review the Flink portable runner translation flow (FlinkStreamingPortablePipelineTranslator) to align the implementation patterns before starting work on the translation framework and Impulse translator.

    My plan is to focus on:

    • URN-based translator dispatch infrastructure
    • KafkaStreamsTranslationContext topology + PCollection mapping
    • ImpulseTranslator using the dedicated bootstrap-topic approach
    • TopologyTestDriver coverage for one-time Impulse emission and unsupported URN validation

    I’ll keep the implementation incremental and Beam-style compliant (nullness-clean, tests included, no unnecessary suppressions).

  2. junaiddshaukat commented on May 30, 2026

    @junaiddshaukat
    ContributorAuthor

    Hi @junaiddshaukat, I’m interested in working on this issue and have started studying the existing Kafka Streams runner skeleton merged in #38534 along with the follow-up design discussion.

    I’ll first sync with the latest integration branch and review the Flink portable runner translation flow (FlinkStreamingPortablePipelineTranslator) to align the implementation patterns before starting work on the translation framework and Impulse translator.

    My plan is to focus on:

    • URN-based translator dispatch infrastructure
    • KafkaStreamsTranslationContext topology + PCollection mapping
    • ImpulseTranslator using the dedicated bootstrap-topic approach
    • TopologyTestDriver coverage for one-time Impulse emission and unsupported URN validation

    I’ll keep the implementation incremental and Beam-style compliant (nullness-clean, tests included, no unnecessary suppressions).

    Thanks for your interest, but this is a reserved for Google summer of code

  3. durgaprasadml commented on May 30, 2026

    @durgaprasadml
    Contributor

    Understood, thanks for the clarification @junaiddshaukat.

  4. junaiddshaukat commented on May 30, 2026

    @junaiddshaukat
    ContributorAuthor

    @durgaprasadml thanks for the interest here, and sorry about the earlier wording — it came out more restrictive than intended.

    This issue is part of the current Kafka Streams runner translation work, which is aligned with the recently merged skeleton + the URN-based dispatch and Impulse translator design from the doc. Because of that, I wanted to avoid anyone starting in a direction that might conflict with the active implementation path.

    That said, there’s a lot of related work in the runner that is not blocked by this issue and would be great for collaboration. I’ll sync with my mentor and put together a clearer breakdown under the tracking issue (#18479) showing:

    what is currently in active GSoC execution path
    what is open for independent contribution
    what can be picked up in parallel once dependencies land

    Happy to help guide you to a good entry point once that list is up.

  5. durgaprasadml commented on Jun 1, 2026

    @durgaprasadml
    Contributor

    Thanks for the clarification @junaiddshaukat — that makes sense.

    I appreciate the detailed context around the active implementation path and dependency flow. I’ll keep following the tracking issue and would definitely be interested in contributing to any parallel or independent runner tasks once they’re identified.

  6. je-ik commented on Jun 15, 2026

    @je-ik
    Contributor

    Closed via #38689.

  7. added this to the 2.75.0 Release milestone on Jun 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions