1

We have a .net core 3.1 web project running with Rebus and Azure Service Bus.

After updating to .NET 5 we can no longer send messages to the Azure Service Bus queue using Rebus. No code changes have been made, only update to .NET 5 and latest Rebus-packages(6.6.1).

var contractMessage = _manager.GetContractMessage();
await _bus.Send(contractMessage);

This throws:

Exception
    Rebus.Exceptions.RebusApplicationException: Could not send to queue 'sbq-queue-queue1'
 ---> System.InvalidOperationException: Operation is not valid due to the current state of the object.
   at Microsoft.Azure.ServiceBus.Core.MessageSender.OnSendAsync(IList`1 messageList)
   at Microsoft.Azure.ServiceBus.RetryPolicy.RunOperation(Func`1 operation, TimeSpan operationTimeout)
   at Microsoft.Azure.ServiceBus.RetryPolicy.RunOperation(Func`1 operation, TimeSpan operationTimeout)
   at Microsoft.Azure.ServiceBus.Core.MessageSender.SendAsync(IList`1 messageList)
   at Rebus.AzureServiceBus.AzureServiceBusTransport.<>c__DisplayClass36_0.<<GetOutgoingMessages>g__SendOutgoingMessagesToDestination|3>d.MoveNext()
   --- End of inner exception stack trace ---
   at Rebus.AzureServiceBus.AzureServiceBusTransport.<>c__DisplayClass36_0.<<GetOutgoingMessages>g__SendOutgoingMessagesToDestination|3>d.MoveNext()
--- End of stack trace from previous location ---
   at Rebus.AzureServiceBus.AzureServiceBusTransport.<>c__DisplayClass36_1.<<GetOutgoingMessages>g__SendOutgoingMessages|1>d.MoveNext()
--- End of stack trace from previous location ---
   at Rebus.Transport.TransactionContext.InvokeAsync(Func`2 actions)
   at Rebus.Transport.TransactionContext.Complete()
   at Rebus.Bus.RebusBus.InnerSend(IEnumerable`1 destinationAddresses, Message logicalMessage)
   at Rebus.Bus.RebusBus.Send(Object commandMessage, IDictionary`2 optionalHeaders)
   at xx.xx.xx.xx.xx.someclass.request.mediatrHandler.Handle(ClassRequest request, CancellationToken cancellationToken) in /home/vsts/work/1/s/xx.xx.xx/Application/xx/xx/xxRequest.cs:line 187

The weird thing is this seems to work when debugging locally, but not on production servers, which are azure virtual machines running IIS. Same hosting bundle as when testing locally in IIS.

To connect to the ASB I have tried both managed identity and full connection string.

Using packages:

Rebus 6.6.1
Rebus.AzureServiceBus 9.0.5
Rebus.Serilog 6.0.0
Rebus.Serviceprovider 6.4.1

And setting up Rebus in the ConfigureServices:

  services.AddRebus((options, serviceProvider) => options
    .Logging(l => l.Serilog())
    .Transport(t => t.UseAzureServiceBusAsOneWayClient(configuration["RebusConfig:AzureServiceBusConnectionString"]))
    .Routing(r => {
      r.TypeBased().MapAssemblyOf<Contract1>(configuration["RebusConfig:Routes:Route1"])
        .MapAssemblyOf<Contract2>(configuration["RebusConfig:Routes:Route2"]);
    })
  );
  • Does this happen consistently in your production environment? Could you clarify exactly which versions you are using of Rebus.AzureServiceBus and Azure.Messaging.ServiceBus? – mookid8000 Sep 07 '21 at 19:35
  • And lastly, maybe see if there's more exception details than what you posted above... it looks quite shallow :) – mookid8000 Sep 07 '21 at 19:36
  • @mookid8000 I added more info to the question. The exception traces are not very telling I'm afraid. This error happens consistently, so no usage of rebus is working in production after the update. Trying it locally hosted in IIS, it works fine and messages are transmitted to ASB correctly. –  Sep 08 '21 at 07:27
  • Which type of connection string are you using in production? Does it contain key/secret? And does it work, when you run the same code with the same connection string locally? – mookid8000 Sep 09 '21 at 09:00
  • In production we were using Connection string with managed identity: Endpoint=sb://secretoiubt.servicebus.windows.net/;Authentication=ManagedIdentity but I've also tried the RootManageSharedAccessKey: Endpoint=sb://secretpoint.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=secret –  Sep 09 '21 at 10:39
  • For managed identity to work, I think you'll need to pass `new DefaultAzureCredentials()` along with the connection string and the queue name - it's the optional `ITokenCredential` parameter in the `UseAzureServiceBus(..)` method – mookid8000 Sep 14 '21 at 06:20

1 Answers1

0

After updating Microsoft Azure packages to the latest version and switching the connections to the new DefaultAzureCredentials() for all azure services this resolved itself.