Possibility to deadletter or abandon a message via a methodcall on AzureServiceBusMessageContext

[fgheysels]

We can currently easily deadletter or abandon a message from inside an AzureServiceBusMessageHandler implementation.
However, when developing you sometimes instantiate other classes and perform further processing of the message there. In some situations though, you need to abandon or deadletter a message.
It would be good if we could easily do this by calling a method on the AzureServiceBusMessageContext instead of having to call the methods that make that happen which are member methods of the AzureServiceBusMessageHandler class.

[stijnmoreels]

Could make the message routing also a lot simpler. I believe that we could mark the AzureServiceBusMessageHandler also deprecated, in that case, in favor of methods on the context.

[stijnmoreels]

Wondering if the 'fallback' functionality has any added-value if we fully expose the Service bus-specific operations via the context.

[fgheysels]

To be honest, I never really understood the 'fallback' functionality. If you need to 'fallback', then I think you (as a user of Arcus.Messaging) really missed implementing some functionality / feature ?

Next to that, wouldn't deprecating AzureServiceBusMessageHandler a huge breaking change ?

[stijnmoreels]

1. the 'fallback' functionality was (I think) implemented to run custom code in case of the message handlers not being matched. Think it is mostely used in scenarios where the type of messages is not always known, too?
2. no, not so much a breaking change. Since this is an additional feature, and especially if we decide to move to the message context, it might be better to deprecate the AzureServiceBusMessageHandler template class (and maybe the entire 'fallback' functionalty with it?).

[lightpeak]

I would also like to ask to look at how to set the deadLetterErrorDescription and deadLetterReason when using Function Apps.

I was unsuccessful because for some reason Arcus kept pushing the default error that 'no suitable handler was found'.

With the latest official servicebus package you can do this out of the box like this:

catch (Exception ex)
{
    await messageActions.DeadLetterMessageAsync(message, ex.GetType().ToString(), ex.Message);
   
}

But back to Arcus. It was suggested to inject the servicebusreceiver manually but this also resulted in an error, because the message actually came in through the function app trigger (with it's own receiver, which had a lock on it) and the servicebusreceiver we initiated was from a different "scope" which as a consequence had no access to the message.

Some guidance would be appreciated!

Thank you and kind regards,
Jelle

[stijnmoreels]

@lightpeak , the "No suitable message handler found" is a message routing thingy that is done by Arcus when the incoming message was not matched with any registered handlers. So, it would mean that there is probably a misconfiguration of message handlers?

For custom dead-lettering (when you want to dead-letter a message in a matching message handler for any reason, which is a different scenario that the on you describe), that will be changed in v3. The ...MessageActions of Azure Functions is also not currently supported, see also ⬇️

Some notes:

• Azure Functions will not be built-in supported starting from v3.
• Fallback message handlers will be deprecated starting from v3.

What you could do, however, is indeed pass in a ServiceBusReceiver implementation to the message routing, that delegates the call to the ...MessageActions, but that still will not provide you with a custom dead-letter reason, bc the dead-lettering is called outside your custom message handler. You first need to have a matching message handler.

public class DelegatedServiceBusReceiver : ServiceBusReceiver
{
    public DelegatedServiceBusReceiver(...MessageActions actions)
    {
        _actions = actions;
    }

    public override Task DeadLetterMessageAsync(...)
    {
         _actions.DeadLetterMessageAsync(...);   
    }
}

public async Task Run([ServiceBusTrigger(...) ServiceBusReceivedMessage message, ...MessageActions actions)
{
    await _messageRouter.RouteMessageAsync(new DelegatedServiceBusReceiver(actions), message, ...);
}

[stijnmoreels]

Done via #551