Message's DeliveryCount should not be modified when a message is peeked

[gmantri]

Actual Behavior

1. Message delivery count is increased by 1

Expected Behavior

1. Message delivery count should not increase

This is more of a clarification question. Let's say I create a queue and send 1 message to that queue. Immediately after sending the message, I fetch that message using PeekAsync().

It is my understanding that because I am just peeking the message and not locking it, the delivery count of that message should not change and I am expecting the delivery count to be 0. However what I am noticing is that the delivery count of that message is 1. If we look at the code here, you will notice that SDK is adding 1 to the value returned by the Service Bus.

I am curious to know why SDK is doing this.

[SeanFeldman]

Given that AmqpMessageConverter is a generic helper class, it doesn't differentiate between use cases (receive vs peek). Therefore this "issue" manifests itself. Saying that, delivery count is meaningless when message is peeked 🙂

[gmantri]

Thanks Sean. I am curious to know why you say that delivery count is meaningless in this case. Wouldn't it create confusion in borderline cases? For example, if I have max delivery count is set as 10 and the actual delivery count is 9 but SDK is reporting it as 10 (because it adds 1 to it).

[SeanFeldman]

What I meant by meaningless is that in the context of a peek operation, there's no delivery. Therefore count doesn't matter. From a correctness point of view, that's a silly bug and should be addressed. Let me fix it.

[gmantri]

Thanks!

[SeanFeldman]

Re-opened so that when the fix is merged this would get closed.

[SeanFeldman]

PR is pending.