How to determine if a message is deferred?

[mlbiam]

Description

I create a Peek client for my queue:

ServiceBusReceiverClient peekClient = new ServiceBusClientBuilder()
            .connectionString(conString)
            .receiver()
            .queueName(myQueue)
            .buildClient();

and retrieve the messages:

ServiceBusReceivedMessage m = null;
        
while ((m = peekClient.peekMessage()) != null) {
    System.out.println(m.getApplicationProperties());
}

There's no property that indicates if a message is deferred though. When I look at a message in servicebusexplorer I can see it's state as Deferred, but there's no "state" property anywhere I can find.

Actual Behavior

1. Peek messages, no indication of the message's "state"

Expected Behavior

1. Property of some kind or method of knowing if a message is in deferred state.

[TomasTokaMrazek]

I think that function peekMessage() does not retrieve deferred messages. You have to use peekMessage(long sequenceNumber). It's the same as function receiveMessages(int maxMessages) and receiveDefferedMessage(long sequenceNumber), which states in javadoc Receives a deferred message. Deferred messages can only be received by using sequence number.

[SeanFeldman]

The service side doesn't support this feature. Please up-vote feature request here: https://github.com/Azure/azure-service-bus/issues/95

[ciaranodonnell]

I feel like this particular behaviour is a bug rather than the absence of the referenced feature. I agree the expected behavior of Peek is to get the next active message. Scheduled messages shouldn't be included until they are active and waiting to be received.

I also think the fact that the EnqueuedTime for the scheduled message when should peeked should so the time it will become active, but it doesn't, it shows the time you peeked. When you receive the message later through a regular receive that time has been updated to the scheduled time.

[EldertGrootenboer]

We have an item on our backlog to give back the state of a message when peeking, however we don't have specific timelines for this yet.

[SeanFeldman]

We have an item on our backlog to give back the state of a message when peeking

That's great, 👏

however we don't have specific timelines for this yet.

In that case, the issue should remain open until it's resolved. Having a comment with an updated status is great to indicate that the issue is not in limbo. Having the issue opened prevents new issues like this from being raised and allows folks to subscribe to get notified when the work is completed, and the feature is available.

[yvgopal]

I am just checking the source code. I see that the issue was fixed sometime last year, and client can read State property in AMQP message annotations with name "'x-opt-message-state". Now SDKs have to read this annotation and set it on the returned Message object.

[EldertGrootenboer]

Thank you for your feedback on this item. We are currently doing active development on this feature, and expect to have more to share around its release in the next couple of months.