So I'm doing what you would think is very basic. Add messages to a queue manually in the web UI to validate basic processing/message hanlder behavior.
I'm using golang with github.com/Azure/azure-storage-queue-go/azqueue
I have a single storage queue and am not consuming messages from the client yet just ensuring all the counts/gets behave as expected as messages appear and disappear. This is in anticipation of I will have multiple instances of the client running that they handle the looks correctly before I bother processing/removing programmatically. And all the queue depth information will eventually be used for scaling automation.
The problem came in when I decided to validate with "expirations". So again just add/delete messages in the Azure portal. I then add a message that expires in 7 seconds. And DON'T delete it. The message properly disappears from the portal. Problem is the ApproximateMessagesCount (which in turn hits the REST api and this header: x-ms-approximate-messages-count:int-value) response count always includes the expired messages as part of the approximate-message-count. It states it "may" be more than actual. But it should eventually come out correct if no messages are moving in/out of the queue.
I assumed this may just take a while to clear - I've waited over an hour. I had max 5 messages and only 1 expired. It shouldn't take that long if there is a delay.
I thought maybe they hit the dead letter queue - Not that I can find (I can't even find that an auto dead letter exists for these queues only the service bus queues)
The ONLY ways I can find to "fix" the issue were
storage explorer (preview) - "clear queue" (not available anywhere else I can find including the Queues view in Storage Accounts)
delete queue (wait) recreate the queue
As far as I can tell this is not a new issue either. I found this is my digging. https://github.com/Azure/azure-storage-net/issues/645
Does anyone have anymore information on how to make this work correctly?
thanks