Is your feature request related to a problem? Please describe.
When consuming Azure Service Bus messages via Brighter, the broker-assigned SequenceNumber is not surfaced to the consuming application. This makes it difficult to uniquely correlate received messages in application logs, traces, or duplicate-detection logic, since the only identifier available in the message header bag is the LockToken (which is a transient peek-lock reference, not a stable message identity).
Describe the solution you'd like
Add SequenceNumber to the Brighter message header bag when mapping an inbound Azure Service Bus message in AzureServiceBusMesssageCreator.MapToBrighterMessage(), following the same pattern already used for LockToken:
- Add
long SequenceNumber { get; } to IBrokeredMessageWrapper
- Implement it in
BrokeredMessageWrapper: public long SequenceNumber => _brokeredMessage.SequenceNumber;
- Add
public const string SequenceNumberBagKey = "SequenceNumber"; to ASBConstants
- In
MapToBrighterMessage(), add: headers.Bag.Add(ASBConstants.SequenceNumberBagKey, azureServiceBusMessage.SequenceNumber);
Consuming handlers can then read it via message.Header.Bag["SequenceNumber"].
Describe alternatives you've considered
Using MessageId to uniquely identify a Service Bus message. However, MessageId is application-defined — it is a free-form string set by the sender and is only enforced as unique if duplicate detection is explicitly enabled on the entity. It is not natively assigned or guaranteed by the broker. By contrast, the SequenceNumber is broker-assigned, read-only, and per the Microsoft documentation "functions as the message's true identifier" — a unique 64-bit integer that is monotonically increasing and gapless.
Additional context
From the Microsoft Service Bus documentation: "The sequence number is a unique 64-bit integer assigned to a message as the broker accepts and stores it. It functions as the message's true identifier."
Is your feature request related to a problem? Please describe.
When consuming Azure Service Bus messages via Brighter, the broker-assigned
SequenceNumberis not surfaced to the consuming application. This makes it difficult to uniquely correlate received messages in application logs, traces, or duplicate-detection logic, since the only identifier available in the message header bag is theLockToken(which is a transient peek-lock reference, not a stable message identity).Describe the solution you'd like
Add
SequenceNumberto the Brighter message header bag when mapping an inbound Azure Service Bus message inAzureServiceBusMesssageCreator.MapToBrighterMessage(), following the same pattern already used forLockToken:long SequenceNumber { get; }toIBrokeredMessageWrapperBrokeredMessageWrapper:public long SequenceNumber => _brokeredMessage.SequenceNumber;public const string SequenceNumberBagKey = "SequenceNumber";toASBConstantsMapToBrighterMessage(), add:headers.Bag.Add(ASBConstants.SequenceNumberBagKey, azureServiceBusMessage.SequenceNumber);Consuming handlers can then read it via
message.Header.Bag["SequenceNumber"].Describe alternatives you've considered
Using
MessageIdto uniquely identify a Service Bus message. However,MessageIdis application-defined — it is a free-form string set by the sender and is only enforced as unique if duplicate detection is explicitly enabled on the entity. It is not natively assigned or guaranteed by the broker. By contrast, theSequenceNumberis broker-assigned, read-only, and per the Microsoft documentation "functions as the message's true identifier" — a unique 64-bit integer that is monotonically increasing and gapless.Additional context
From the Microsoft Service Bus documentation: "The sequence number is a unique 64-bit integer assigned to a message as the broker accepts and stores it. It functions as the message's true identifier."