Issue receiving messages from azure service bus using managed identity connections string

we are using the nsb with azure functions (httptrigger) along with managed identity (DefaultAzureCredentials)

when running locally using managed identity connection string we are able send messages but the handler is not able receive messages, the message is just sitting in the queue. however if we use a shared access key in the connection string, the handler is able to receive messages.

when running in cloud, using managed identity connection string, nsb is able to send and receive message without any issues.

to rule out any security issues locally we granted the developer a owner access to azure service bus, nsb does not throw any errors, from what i understand about handler if there is no matching handler an exception is thrown by nsb, i dont see any exception the message is just sitting in the quque.

any diagnostics that i can enable here ?

thanks -Nen

Could you clarify how your function is triggered? There’s something inconsistent in the description between


This is likely related to your local setup as NServiceBus does not receive messages, Azure Functions runtime does and delegates that to your Function/NServiceBus. If you want to troubleshoot the issue, you could take NServiceBus out of the equation completely and see why the Service Bus trigger is not triggered locally.

Hi @SeanFeldman,

we are using the following code below.

  public async Task<IActionResult> Run(
      [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest request, ExecutionContext executionContext, ILogger logger)
    var sendOptions = new SendOptions();

    var sampleMsg= new SampleMessage()
      EventId = Guid.NewGuid(),
    await _functionEndpoint.Send(sampleMsg, sendOptions, executionContext, logger);
    return new OkObjectResult($" sent. ");

Thank you, @Nen_Zax.

The code you’ve shared has no Service Bus trigger. It’s an HTTP triggered function that send a message as a result of an incoming HTTP request (GET or POST). Therefore messages are not consumed by this function from any queue.

If I’d have to guess, you might have a different endpoint that is consuming from the queue in question, and locally is not present, causing messages not to be consumed. But it’s definitely not this functions that’s at fault.