Subscription endpoint not being called using Pub/Sub

[conradcreel]

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]

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]

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]

@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]

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. 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 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.

Also some reference from Apple

[conradcreel]

@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]

@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]

@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]

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 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]

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]

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]

Have you checked the Scopes in both publisher and Subscriber?

[halspang]

@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]

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.