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

Subscription endpoint not being called using Pub/Sub #803

Closed
conradcreel opened this issue Dec 13, 2021 · 14 comments
Closed

Subscription endpoint not being called using Pub/Sub #803

conradcreel opened this issue Dec 13, 2021 · 14 comments
Labels
area/client/pubsub kind/bug Something isn't working

Comments

@conradcreel
Copy link

Tried a bare bones pub/sub sample with dapr 1.5.1 and the Subscribing endpoint is never called. Everything seems to be configured correctly and publishing works fine.

Program.cs looks like:

var builder = WebApplication.CreateBuilder(args);   
builder.Services.AddControllers().AddDapr();  
var app = builder.Build();  
//app.UseHttpsRedirection();  
app.UseCloudEvents();  
app.UseAuthorization();  
app.MapControllers();  
app.MapSubscribeHandler();  
app.Run();

PublisherController.cs looks like:

using Dapr.Client;
using Microsoft.AspNetCore.Mvc;

namespace DaprPubSub.Controllers;

[ApiController]
public class PublisherController : ControllerBase
{
    private readonly DaprClient _DaprClient;
    private readonly ILogger<PublisherController> _logger;

    public PublisherController(ILogger<PublisherController> logger, DaprClient daprClient)
    {
        _logger = logger;
        _DaprClient = daprClient;
    }

    [HttpGet("publish")]
    public async Task<IActionResult> PublishMessage([FromQuery] int s)
    {
        CancellationTokenSource source = new CancellationTokenSource();
        CancellationToken cancellationToken = source.Token;
        var data = new MyEvent
        {
            Data = s
        };
        await _DaprClient.PublishEventAsync("pubsub", "my_topic", data, cancellationToken);
        _logger.LogInformation($"Published message: {data.Data}");

        return Ok(data);
    }
}

SubscriberController.cs looks like:

using Microsoft.AspNetCore.Mvc;
using Dapr;

namespace DaprPubSub.Controllers;

[ApiController]
public class SubscriberController : ControllerBase
{
    private readonly ILogger<SubscriberController> _logger;

    public SubscriberController(ILogger<SubscriberController> logger)
    {
        _logger = logger;
    }

    [Topic("pubsub", "my_topic")]
    [HttpPost("subscribe")]
    public void HandleMessage([FromBody] MyEvent e)
    {
        _logger.LogInformation("Subscriber received : " + e.Data);
    }
}

Calling /dapr/subscribe returns:
[{"topic":"my_topic","pubsubName":"pubsub","route":"subscribe"}]

And I can successfully publish from the /publish endpoint and the CLI. Additionally I can call the /subscribe endpoint directly with an HTTP Post so it's not a routing issue.

Shouldn't matter but I'm using the default pubsub.yaml with Redis.

Any ideas?

Thanks!

@bitTobiasMeier
Copy link

bitTobiasMeier commented Dec 13, 2021

I have the same problem. But if I use the topic name for the HttpPost attribute, then it works.
[Topic("pubsub", "order")]
[HttpPost("order")]
public void HandleMessage(MyEvent e)
{
_logger.LogInformation("Subscriber received : " + e.Data);
}

@conradcreel
Copy link
Author

I have the same problem. But if I use the topic name for the HttpPost attribute, then it works. [Topic("pubsub", "order")] [HttpPost("order")] public void HandleMessage([FromBody] MyEvent e) { _logger.LogInformation("Subscriber received : " + e.Data); }

I tried that as a curiosity but still same behavior on my end--subscriber never picks up the message

@halspang
Copy link
Contributor

@conradcreel - Have you tried running the ControllerSample in the repo? That could show if the endpoints are being setup correctly.

When you run the app, do you see a log message like this?

INFO[0043] app is subscribed to the following topics: [deposit withdraw] through pubsub=pubsub  app_id=controller instance=Hals-MacBook-Pro.local scope=dapr.runtime type=log ver=edge

Or do you see an error like this?

ERRO[0000] app returned http status code 403 from subscription endpoint  app_id=controller instance=Hals-MacBook-Pro.local scope=dapr.runtime type=log ver=edge 

@Weidaicheng
Copy link

Hey guys @conradcreel @bitTobiasMeier @halspang , I figured it out!
I'm sure the ur using mac too, there is a Control Center process on Mac which is listening on 5000 prot.
I call the /dapr/subscribe from postman when none of my apps running, I got a 403 code.
image
So I'm sure there is some other process which is listening on 5000, so I run the command lsof -i:5000 and got below informations
image
The ControlCe process is listening on 5000!
Then I change my app port to 6000 by running dapr run --app-id sub-csharp --app-port 6000 -- dotnet run --urls=http://localhost:6000 and got no errors.
image

Also some reference from Apple

@conradcreel
Copy link
Author

@Weidaicheng - I'll try playing with the ports but I'm running this on Linux. Also I didn't have an issue calling /dapr/subscribe (and getting the right endpoint in the response). Literally everything works perfectly... except the handler isn't firing--verified by calling it directly versus publishing a message. The former writes to the log, the latter does nothing.

@halspang
Copy link
Contributor

@Weidaicheng - I'll try playing with the ports but I'm running this on Linux. Also I didn't have an issue calling /dapr/subscribe (and getting the right endpoint in the response). Literally everything works perfectly... except the handler isn't firing--verified by calling it directly versus publishing a message. The former writes to the log, the latter does nothing.

Can you share any logs from your dapr sidecar or application? It'd be good to see what kind of error you're getting.

@Weidaicheng
Copy link

@Weidaicheng - I'll try playing with the ports but I'm running this on Linux. Also I didn't have an issue calling /dapr/subscribe (and getting the right endpoint in the response). Literally everything works perfectly... except the handler isn't firing--verified by calling it directly versus publishing a message. The former writes to the log, the latter does nothing.

A log would be perfect, so we can check that out🤓

@Weidaicheng
Copy link

I have the same problem. But if I use the topic name for the HttpPost attribute, then it works. [Topic("pubsub", "order")] [HttpPost("order")] public void HandleMessage([FromBody] MyEvent e) { _logger.LogInformation("Subscriber received : " + e.Data); }

I tried that as a curiosity but still same behavior on my end--subscriber never picks up the message

I check your code above, and from my understanding, you can't use the event message entity directly by default, you should wrap your own entity class by the dapr message like this
image
And also here is the SubMessage definition

/// <summary>
/// Sub message
/// </summary>
/// <typeparam name="T"></typeparam>
public class SubMessage<T>
    where T : IntegrationEvent
{
    public string SpecVersion { get; set; }
    public string DataContentType { get; set; }
    public string Source { get; set; }
    public string Type { get; set; }
    public string Topic { get; set; }
    public string PubSubName { get; set; }
    public string TraceId { get; set; }
    public string Id { get; set; }
    public T Data { get; set; }
}

@SarangRapid
Copy link

similar thing I m facing, pub is working fine, while sub is not getting hit, using service bus queue, dapr/subscription is there on the subscription endpoint, logs confirmed pubsub loaded while running subscription client.

time="2022-01-20T12:35:39.7773741+05:30" level=info msg="component loaded. name: pubsub, type: pubsub.azure.servicebus/v1" app_id=dapr_statechange_app instance=PUN-NB-LED6Z3D scope=dapr.runtime type=log ver=1.5.1

@Weidaicheng
Copy link

similar thing I m facing, pub is working fine, while sub is not getting hit, using service bus queue, dapr/subscription is there on the subscription endpoint, logs confirmed pubsub loaded while running subscription client.

time="2022-01-20T12:35:39.7773741+05:30" level=info msg="component loaded. name: pubsub, type: pubsub.azure.servicebus/v1" app_id=dapr_statechange_app instance=PUN-NB-LED6Z3D scope=dapr.runtime type=log ver=1.5.1

Can u share ur code?

@BhargavaM91
Copy link

Have you checked the Scopes in both publisher and Subscriber?

@halspang
Copy link
Contributor

@SarangRapid - You also need to see a message like:

INFO[0043] app is subscribed to the following topics: [deposit withdraw] through pubsub=pubsub  app_id=controller instance=Hals-MacBook-Pro.local scope=dapr.runtime type=log ver=edge

If you see something like that, we know your subscriptions are actually being loaded. The component loading is just the actual connection to the service. Aside from that, nothing is actually happening yet.

@JacobButcherForge
Copy link

I ran into a similar issue while trying to work through the Publish and Subscribe quickstart guide using the .NET samples. I am working on a Mac. Turns out it was a simple port configuration mismatch issue. The port in the quickstart documentation here doesn't currently match the port in the code sample here

Updating the Dapr run --app-port argument to match the port the ASP.NET Core app is listening on fixed the issue. Suggest checking all of the port configurations in your setup.

Also, the Dapr documentation needs to be updated to match the code samples.

@WhitWaldo
Copy link
Contributor

I'm going to close this as the port in the .NET quickstart presently matches the port in the .NET sample meaning they should work without further configuration.

Please don't hesitate to re-open this or file another ticket if you're still experiencing this issue.

@WhitWaldo WhitWaldo added area/client/pubsub kind/bug Something isn't working labels Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/client/pubsub kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

8 participants