I found a case where the emulator responds differently than the real servicebus service. It's probably an edge case, but thought you might want to know about it.
I am using the package Azure.Messaging.ServiceBus 7.15.0
If I send a message with an added "application property" that has a null value, the real servicebus service will accept the request and enqueue the message, but with the emulator I get an exception back indicating that the request to send the message was cancelled (no further information about why).
var serviceBusClient = new ServiceBusClient(<ConnectionString>);
var sender = serviceBusClient.CreateSender(<TopicName>);
var message = new ServiceBusMessage("body");
message.ApplicationProperties.Add(new KeyValuePair<string, object?>("key", null));
await sender.SendMessageAsync(message, cancellationToken);
When pointed at the emulator, the call to SendMessageAsnyc throws this exception about 14 seconds later:
Azure.Messaging.ServiceBus.ServiceBusException: The operation was canceled. (ServiceCommunicationProblem). For troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.
---> System.OperationCanceledException: The operation was canceled.
at Microsoft.Azure.Amqp.AsyncResult.End[TAsyncResult](IAsyncResult result)
at Microsoft.Azure.Amqp.SendingAmqpLink.<>c.<SendMessageAsync>b__12_1(IAsyncResult r)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location ---
at Azure.Messaging.ServiceBus.Amqp.AmqpSender.SendBatchInternalAsync(AmqpMessage batchMessage, TimeSpan timeout, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at Azure.Messaging.ServiceBus.Amqp.AmqpSender.SendBatchInternalAsync(AmqpMessage batchMessage, TimeSpan timeout, CancellationToken cancellationToken)
at Azure.Messaging.ServiceBus.Amqp.AmqpSender.<>c.<<SendAsync>b__24_0>d.MoveNext()
--- End of stack trace from previous location ---
at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.<>c__22`1.<<RunOperation>b__22_0>d.MoveNext()
--- End of stack trace from previous location ---
at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.RunOperation[T1,TResult](Func`4 operation, T1 t1, TransportConnectionScope scope, CancellationToken cancellationToken, Boolean logTimeoutRetriesAsVerbose)
at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.RunOperation[T1,TResult](Func`4 operation, T1 t1, TransportConnectionScope scope, CancellationToken cancellationToken, Boolean logTimeoutRetriesAsVerbose)
at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.RunOperation[T1](Func`4 operation, T1 t1, TransportConnectionScope scope, CancellationToken cancellationToken)
at Azure.Messaging.ServiceBus.Amqp.AmqpSender.SendAsync(IReadOnlyCollection`1 messages, CancellationToken cancellationToken)
at Azure.Messaging.ServiceBus.ServiceBusSender.SendMessagesAsync(IEnumerable`1 messages, CancellationToken cancellationToken)
at Azure.Messaging.ServiceBus.ServiceBusSender.SendMessageAsync(ServiceBusMessage message, CancellationToken cancellationToken)
But if I point the same code to a real service bus namespace, it will produce the message
I found a case where the emulator responds differently than the real servicebus service. It's probably an edge case, but thought you might want to know about it.
I am using the package Azure.Messaging.ServiceBus 7.15.0
If I send a message with an added "application property" that has a null value, the real servicebus service will accept the request and enqueue the message, but with the emulator I get an exception back indicating that the request to send the message was cancelled (no further information about why).
When pointed at the emulator, the call to SendMessageAsnyc throws this exception about 14 seconds later:
But if I point the same code to a real service bus namespace, it will produce the message