[FEATURE REQ] Introduce abstraction similar to IMessageReceiver implemented by ServiceBusMessageActions

Library name

Azure.Messaging.ServiceBus Microsoft.Azure.WebJobs.Extensions.ServiceBus

Please describe the feature.

Microsoft.Azure.ServiceBus had an IMessageReceiver interface that allows abandoning, completing, etc but has no equivalent in the Azure.Messaging.ServiceBus.

ServiceBusMessageActions (and one could argue other classes such as ServiceBusReceiver, ProcessMessageEventArgs, ProcessSessionMessageEventArgs) should implement an interface to allow abstraction.

Task AbandonMessageAsync(ServiceBusReceivedMessage message, IDictionary<string, object> propertiesToModify = null, CancellationToken cancellationToken = default);
Task CompleteMessageAsync(ServiceBusReceivedMessage message, CancellationToken cancellationToken = default) { throw null; }
Task DeadLetterMessageAsync(ServiceBusReceivedMessage message, IDictionary<string, object> propertiesToModify = null, CancellationToken cancellationToken = default);
Task DeadLetterMessageAsync(ServiceBusReceivedMessage message, string deadLetterReason, string deadLetterErrorDescription = null, CancellationToken cancellationToken = default);
Task DeferMessageAsync(ServiceBusReceivedMessage message, IDictionary<string, object> propertiesToModify = null, CancellationToken cancellationToken = default);
Task RenewMessageLockAsync(ServiceBusReceivedMessage message, CancellationToken cancellationToken = default);

This would essentially allow us to replace references to IMessageReceiver in Microsoft.Azure.ServiceBus with something new without having to introduce dependencies (and coupling) to Microsoft.Azure.Webjobs.Extensions.ServiceBus .

This might also help in addressing the testing concerns raised in #25375

[4nandP]

How would you suggest writing a piece of functionality that will call for example Abandon that can be consumed by Microsoft.Azure.Webjobs.Extensions.ServiceBus but also be consumable by something using Azure.Messaging.ServiceBus directly (i.e. something agnostic of the hosting mechanism)? I fear the initial response is too focused on an aside about testing and mocking rather than the fact that I would have to otherwise introduce coupling with the webjobs packages.

This just pushes the concern to the consumer because we’d have to define the interface in our library that originally used IMessageReceiver and then implement it as a decorator around either ServiceBusReceiver or ServiceBusMessageActions as appropriate. That seems over the top vs implementing an interface within the framework for something that doesn’t seem to have changed much over the years. I’m trying to avoid coupling with the hosting layer so that the same library can be used by code running in a function app, console, docker etc, i.e. host agnostic.

/unresolve

[msftbot[bot]]

Hi @4nandP. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.