Routing to separated handlers for a given message type?

[CharlieDigital]

I noticed that the default behavior of the consumers for a given message type is to "bundle" the consumers.

For example, for a message type:

public class EmailReceivedModel() : Event(Id.Random())
{
    public string To { get; set; } = string.Empty;
    public string From { get; set; } = string.Empty;
    public string Subject { get; set; } = string.Empty;
    public string Body { get; set; } = string.Empty;
}

If I have two RequestHandlerAsync<EmailReceivedModel>, they both consume the same message.

Is there a mechanism to have separated consumers such that each handler is able to produce its own subscriber channel?

EmailReceivedMessage ---> [published_topic] |---> [subscriber_A] ---> class A : RequestHandlerAsync<EmailReceivedModel>
                                            |---> [subscriber_B] ---> class B : RequestHandlerAsync<EmailReceivedModel>
                                            |---> [subscriber_C] ---> class C : RequestHandlerAsync<EmailReceivedModel>

I know I can create three subscriptions when setting up the consumers, but I see no obvious way to route the subscriptions to specific handlers.

[lillo42]

Unfortunately, today there is no way to do it via Subscription, you can do a workaround, by having a message X and publishing it to the internal bus

Like

EmailReceived-> [published_topic] -> [subscriber_1] -> RequestHandlerAsync<EmailReceived>  |-> RequestHandlerAsync<EmailReceivedModel>
                                                                                           |-> RequestHandlerAsync<EmailReceivedModel>
                                                                                           |-> RequestHandlerAsync<EmailReceivedModel>

The message

public class EmailReceived() : Event(Id.Random())
{
    public string To { get; set; } = string.Empty;
    public string From { get; set; } = string.Empty;
    public string Subject { get; set; } = string.Empty;
    public string Body { get; set; } = string.Empty;
}


public class EmailReceivedModel() : Event(Id.Random())
{
    public string To { get; set; } = string.Empty;
    public string From { get; set; } = string.Empty;
    public string Subject { get; set; } = string.Empty;
    public string Body { get; set; } = string.Empty;
}

So your handler will be something like this:

public class EmailReceived(IAmACommandProcessor processor) : RequestHandlerAsync<EmailReceived>()
{
    public override Task<EmailReceived> HandleAsync(EmailReceived request, CancellationToken ct)
    {
         await processor.PublishAsync(new EmailReceivedModel { ... });
         return base.HandleAsync(request, ct);
    }
}

[CharlieDigital]

Yes; the downside to this approach is that on redrive, all three handlers are going to fire so idempotency has to managed outside of Brighter/queue. Ideally, by using separated queues and handlers, then idempotency on redrive is automatic.

With separated subscriptions, idempotency isn't an issue on redrive since the queue itself manages this.

Is this outside of the design goals of Brighter?

The reason I ask is whether it would make sense to potentially add this behavior to Brighter or if the team just fundamentally disagrees with this architectural decision.