By removing the visible count you are not actually achieving what you are suggesting in #4002

By removing the visible count you are not actually achieving what you are suggesting in #4002

Removing the visible count will return the approximate message count directly, which contains messages that are queued and being processed. Not sure if there is anything wrong? @tomkerkhove

/run-e2e azure_queue
Update: You can check the progress here

I have misread the issue, no worries.

Can you add an entry in the changelog please?

I've pinged @ahmelsayed privately as well to see if we can remember why we added that.

@ahmelsayed pointed out that this was changed in #2613 by @RamCohen as an optimization.

I think the optimization is still OK to have and we can skip this PR but I don't have a strong opinion.

@tomkerkhove This optimization looks make sense to me. But the issue is not related to the optimization, but the visible message count used to count queue length.

Let's say "queue length" parameter is 1, there are 20 messages and scaled out to 20 instances and pulled message from queue, the queue size returned is 0 （visible message account）, but the actual value should be 20 (approximate queue length).

I'm shipping a custom version of this scaler in production since v2.6.1. My custom versions have the exact same code as in this pull request, and they have been working perfectly fine for the past year. ApproximateMessageCount is the way to go.
There are multiple issues about this problem(eg: #2385 #3555).

The optimization done with #2613 will be useless, because we should always call GetProperties to get the ApproximateMessageCount.

I hope this will be merged soon.
Thanks

@tomkerkhove @zroubalik Can you take a look at this pr?

/run-e2e azure_queue

Update: You can check the progress here

/run-e2e azure_queue*
Update: You can check the progress here

Thanks team, this is great!