Skip to content

Flux Streaming subscriptions with generic type #1616

Description

@alicejgibbons

Today using Flux with streaming subscriptions in Java, you can only publish/subscribe using Dapr's CloudEvent type as shown in the example here:

The latest PR by @artur-ciocanu is an improvement since subscribeToEvents() uses a flux based method but the limitation here is that only the CloudEvent can be sent.

We should also support something like the following as many users will be sending generic types (not cloud event based) on the message broker and this is supported in Dapr Pubsub generally.

public <T> Flux<T> subscribeToEvents(...

One way to standardize this would be to add an override that uses the DaprAppCallbackProtos.TopicEventRequest topicEventRequest type which can be deserialized as per the example here: https://github.com/artur-ciocanu/java-sdk/blob/26d215342bf541135c200ba22fd085b8a4e1c010/examples/src/main/java/io/dapr/examples/pubsub/grpc/SubscriberGrpcService.java#L67

Activity

  1. alicejgibbons commented on Jan 7, 2026

    @alicejgibbons
    Author

    Note even the old subscribeToEvents() method that doesn't use Flux seems to convert to CloudEvents: https://github.com/dapr/java-sdk/blob/master/sdk/src/main/java/io/dapr/client/Subscription.java#L94

  2. artur-ciocanu commented on Jan 9, 2026

    @artur-ciocanu
    Contributor

    @alicejgibbons exactly, I tried to follow the current pattern for anything related to subscription. Since the Flux based API is pretty new, it still marked as "preview", I am wondering if there is any value in exposing the CloudEvent based API or should replace the current API with the generic one. I want to make that we keep the API surface small.

    Let me know your thoughts and what customers are looking for.

  3. alicejgibbons commented on Jan 9, 2026

    @alicejgibbons
    Author

    @artur-ciocanu Replacing the current API could be a good option since users could still use the Dapr Java CloudEvent object as the generic type anyways and get the same result. This also avoids the code around having to rebuild the CoudEvent object which doesn't take into account all of the cloudevent fields here.

    Lots of users DO use cloudevents though so leaving both in is also fine for ease of use :)

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

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions