Service Bus Explorer subscribing to a namespace listing all queues and messages causing settlement issues in a .NET 8 Worker Service subscriber that is being debugged/running on the same machine

[ajinkyaSurve]

---

Azure.Messaging.ServiceBus 7.20.1 — DeadLetterAsync / AbandonAsync using AmqpWebSocket dropping messages silently when there is a instance of Service Bus Explorer subscribing to the same namespace running actively on same machine.

Summary

In Azure.Messaging.ServiceBus 7.20.1, calls to DeadLetterMessageAsync and AbandonMessageAsync
appear to silently drop messages instead of moving them to the dead-letter sub-queue or returning
them to the active queue for redelivery.
This is observed when a instance of Service Bus Explorer is running in parallel subscribing to the same namespace

---

Environment

Package	Azure.Messaging.ServiceBus
Version	7.20.1
Target framework	.NET 8
C# version	12.0
Host	.NET Worker Service (Windows Service)
Queue mode	PeekLock (manual settlement)

---

Affected Settlement Calls

• ServiceBusReceiver.DeadLetterMessageAsync(message, reason, description, cancellationToken)
• ServiceBusReceiver.AbandonMessageAsync(message, cancellationToken)

---

Observed Behavior

• Service Bus Explorer is running in parallel subscribing to the same namespace
• DeadLetterMessageAsync completes without throwing, but the message does not appear in the
  dead-letter sub-queue ($DeadLetterQueue).
• AbandonMessageAsync completes without throwing, but the message is not requeued and the
  DeliveryCount is not incremented.
• In both cases, the message is silently dropped — no exception, no log from the SDK, no trace.
• No trace of messages in Azure SBN broker checked through portal
• DeadLetter and Abandon actions recorded in App Insights.
• Stopping the Service Bus Explorer lets the messages settle through the debugged Worker Service as expected using DeadLetterAsync and AbandonAsync.

---

Expected Behavior

• Service Bus Explorer is running in parallel subscribing to the same namespace
• DeadLetterMessageAsync called from within a .Net 8 Worker Service being debugged locally should move the message to <queue>/$DeadLetterQueue with the supplied deadLetterReason and deadLetterErrorDescription properties set.
• AbandonMessageAsync called from within a .Net Worker Service being debugged locally should release the message lock and return the message to the active queue, incrementing DeliveryCount.

---

Reproduction Steps

Run Service Bus Explorer by connecting to a specific Service Bus Namespace
Using the same Service Bus Namespace inside a .NET 8 Worker Service perform settlement calls on messages subscribed from a given queue.

[SeanFeldman]

@ajinkyaSurve this reads like a dump from an AI agent.
Could you provide specific steps to reproduce the issue you're running into? Thank you.

[ajinkyaSurve]

LOL! thank you @SeanFeldman for looking into this, the issues details were indeed generated using AI. But not by an agent 😁

Here are the steps to reproduce -

---WHEN DOES IT WORK---

1. Service Bus Explorer is closed
2. Visual Studio 2022 is debugging a Windows Service
3. Round-Robin Queue Polling Loop (2 queues from SBNS Endpoint=sb://xyz.servicebus.windows.net)
4. A class which is BackgroundService
   1. Uses ReceiveMode.PeekLock, PrefetchCount = 0 and ServiceBusTransportType.AmqpWebSockets (corporate n/w)
   2. Processes one message from respective queue at a time, no multi-threading
   3. CompleteAsync settles the message. (Not an issue when a Service Bus Explorer instance is not running).
   4. DeadLetterAsync/AbandonAsync settles the message and puts it into respective DLQ. (Works fine when there is NO Service Bus Explorer OPEN on the same machine that is running the Visual Studio 2022)

---WHEN DOES IT FAIL---

1. Service Bus Explorer is open and connected to Endpoint=sb://xyz.servicebus.windows.net
2. Visual Studio 2022 is debugging a Windows Service
3. Round-Robin Queue Polling Loop (2 queues from SBNS Endpoint=sb://xyz.servicebus.windows.net)
4. A class which is BackgroundService
   1. Uses ReceiveMode.PeekLock, PrefetchCount = 0 and ServiceBusTransportType.AmqpWebSockets (corporate n/w)
   2. Processes message from respective queue at a time, no multi-threading
   3. CompleteAsync is also probably facing the settlement issue, kind of like false positive in this case.
   4. DeadLetterAsync/AbandonAsync settlement fails without any exception and the message is nowhere to be found (Only when there is Service Bus Explorer instance open and running on the same machine that is running the Visual Studio 2022)

[SeanFeldman]

If I read this correctly, the assumption is that having an SBE running and connected to the same ASB namespace from the same machine that consumes messages is causing message settlement to fail? I'm not sure how that would work as this is a very typical scenario to have the developed system running on a dev box and have the SBE opened and connected to the same namespace.

Since you know how to reproduce this, can you share a minimal repro (code) and I'll take a look at it.

[SeanFeldman]

@ajinkyaSurve haven't heard anything back. Does that mean the issue is no longer happening? I'll close it. Feel free to re-open if you have a minimal repro to share for us to look into. Thank you.