Service Bus: Sessions, Dead-Lettering, and Duplicate Detection

Azure Service Bus provides several advanced features that go beyond basic send-and-receive. Sessions enable ordered, grouped message processing. Dead-lettering ensures that problematic messages are not lost. Duplicate detection prevents the same message from being processed twice. This lesson explores each of these features in depth and explains when to use them.

---

Sessions

By default, messages in a Service Bus queue or subscription are delivered in FIFO order, but with competing consumers, multiple messages can be processed in parallel — meaning the overall processing order is not guaranteed.

Sessions solve this by grouping related messages and ensuring that all messages within a session are processed sequentially by a single consumer.

How Sessions Work

1. Each message is assigned a sessionId — a string that identifies the group
2. The queue or subscription must have sessions enabled at creation time
3. A consumer accepts a session and receives a lock on all messages with that session ID
4. Only one consumer can process a given session at a time
5. Different sessions can be processed in parallel by different consumers

Consumer A <-- Session "order-001" [ msg1, msg2, msg3 ]
Consumer B <-- Session "order-002" [ msg4, msg5 ]
Consumer C <-- Session "order-003" [ msg6, msg7, msg8, msg9 ]

Creating a Session-Enabled Queue

az servicebus queue create \
  --name order-processing \
  --namespace-name sb-demo-ns \
  --resource-group rg-messaging \
  --enable-session true

Sending Session Messages

await sender.sendMessages([
  { body: { step: 'validate' }, sessionId: 'order-001' },
  { body: { step: 'charge' }, sessionId: 'order-001' },
  { body: { step: 'fulfil' }, sessionId: 'order-001' },
]);

Receiving Session Messages

const receiver = client.acceptSession('order-processing', 'order-001');

const messages = await receiver.receiveMessages(10);
for (const msg of messages) {
  console.log(`Processing ${msg.body.step} for session ${msg.sessionId}`);
  await receiver.completeMessage(msg);
}

Alternatively, use acceptNextSession() to accept whichever session has messages available.

Session State

Each session can store a small amount of state (up to 256 KB) that persists across receive operations:

// Set session state
await receiver.setSessionState(Buffer.from(JSON.stringify({ step: 2 })));

// Get session state
const state = await receiver.getSessionState();

Session state is useful for checkpointing progress in multi-step workflows.

---

Dead-Letter Queue

The dead-letter queue (DLQ) is a special sub-queue attached to every Service Bus queue and subscription. Messages that cannot be processed are moved here instead of being discarded.

When Messages Are Dead-Lettered

Messages are moved to the DLQ in several scenarios:

Scenario	Description
Max delivery count exceeded	The message has been received and abandoned maxDeliveryCount times
TTL expired	The message's time-to-live has elapsed (if deadLetteringOnMessageExpiration is enabled)
Filter evaluation error	A subscription filter fails to evaluate the message
Explicit dead-lettering	The consumer calls deadLetterMessage() with a reason

Accessing the Dead-Letter Queue

The DLQ is accessed using a special path: