Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to subscribe an enpoint to multiple pub-subs #715

Closed
mmisztal1980 opened this issue Jul 12, 2021 · 2 comments · Fixed by #763
Closed

Unable to subscribe an enpoint to multiple pub-subs #715

mmisztal1980 opened this issue Jul 12, 2021 · 2 comments · Fixed by #763
Assignees
Labels
kind/bug Something isn't working
Milestone

Comments

@mmisztal1980
Copy link

mmisztal1980 commented Jul 12, 2021

Expected Behavior

Having registered multiple different pubsubs (redis streams & rabbit) to an endpoint, I expected that the endpoint would subscribe to all of them. This was interesting to me because I was testing if I could have HA on the pubsub(s) by having multiple instances of it (for instance 2x separate rabbitmq instances)

Actual Behavior

When using .WithTopic multiple times, it appears that the last registered pubsub wins.

I've tested it by :

  • commenting out the 2nd pubsub, to verify that the 1st pubsub works as intended
  • inverting the order in which pubsubs were registered to verify that "last one wins" theory - the test confirmed it.

Why I feel this is not the expected behavior:

  • The IEndpointConventionBuilder's .WithTopic fluent API seems to be designed to allow such situation(s).
  • The .WithTopic xml docs does not explicitly state that this is not allowed
  • Under the hood, .WithTopic adds a TopicAttribute to the underlying builder's metadata - which should conceptually work at 1st glance
  • I can imagine a scenario where a event can originate from 2 different sources. Therefore I'd like to adhere to the DRY rule and handle the said event at a single location

Steps to Reproduce the Problem

Sample C# code to reproduce the problem:

endpoints
   .MapPost("/orders", async context =>
  {
    var order = await JsonSerializer.DeserializeAsync<Order>(context.Request.Body);
    this.Service.Logger.LogInformation($"Order {order.Id} received");                        
  })
  .WithTopic(Constants.PubSub.RedisStreams, Constants.OrdersTopicName)
  .WithTopic(Constants.PubSub.RabbitMq, Constants.OrdersTopicName);

Release Note

RELEASE NOTE:
Fixed an issue which prevented registering multiple pubsub subscriptions on to an endpoint.

@mmisztal1980 mmisztal1980 added the kind/bug Something isn't working label Jul 12, 2021
@rynowak
Copy link
Contributor

rynowak commented Sep 28, 2021

@halspang - can you look into this?

@halspang
Copy link
Contributor

halspang commented Oct 7, 2021

@rynowak - Testing this out myself and it is stopping me from subscribing to two topics as well.

Current working theory is that the metadata that we're adding to the builder is overwriting old metadata instead of adding more. I'll look deeper and find a solution.

halspang added a commit to halspang/dotnet-sdk that referenced this issue Oct 20, 2021
Using the WithTopic builder pattern allows you to specify multiple
topics that route to a single endpoint. Given the topics are unique,
this should be a valid case.

This change allows for a single endpoint to bind to multiple topics.
Note that this can only be done via the EndpointBuilder and not the
TopicAttribute.

dapr#715
rynowak pushed a commit that referenced this issue Oct 26, 2021
* Allow multiple topics to call the same endpoint

Using the WithTopic builder pattern allows you to specify multiple
topics that route to a single endpoint. Given the topics are unique,
this should be a valid case.

This change allows for a single endpoint to bind to multiple topics.
Note that this can only be done via the EndpointBuilder and not the
TopicAttribute.

#715

* Let TopicAttribute to be specified multiple times

The endpoint builder allowed for multiple WithTopic calls so the
attribute should match that behavior.
@halspang halspang added this to the v1.5 milestone Nov 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants