Azure Storage Queue Scaler: should report both visible and invisible message count to compute queue length.

[moria97]

Report

From Azure Storage Queue document, queue messages should be set to invisible state when pulled from queue for processing, deleted when processing completes and be visible again when processing fails. So when computing queue length for scaling, it's better to consider both visible and invisible messages like in the get-queue-length documentation instead of counting those visible only.

Expected Behavior

Use correct queue length to count both visible and invisible messages.

Actual Behavior

Count only visible messages.

Steps to Reproduce the Problem

None

Logs from KEDA operator

example

KEDA Version

None

Kubernetes Version

None

Platform

None

Scaler Details

Azure Storage Queue

Anything else?

No response

[JorTurFer]

Hi,
It makes sense, but maybe there is any reason behind that behavior. Do you know why we don't call directly to ApproximateMessagesCount() @ahmelsayed ?
Maybe you could now the reason too (or not) @v-shenoy

[v-shenoy]

I am not really sure why this was implemented this way. Ahmed will know better.

[JorTurFer]

Let's wait till @ahmelsayed has time to answer us before continue with the PR

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed due to inactivity.

[JorTurFer]

@ahmelsayed, do you have more info?

[jellevankerk]

@JorTurFer @moria97 I think this fix has introduced a bug for me. It no longer scales down if there are invisible messages in the queue (Which is good). However, it also keeps scaling up on these invisible messages. Was this expected behavior, if yes is there some way to disable this behaviour

[JorTurFer]

@JorTurFer @moria97 I think this fix has introduced a bug for me. It no longer scales down if there are invisible messages in the queue (Which is good). However, it also keeps scaling up on these invisible messages. Was this expected behavior, if yes is there some way to disable this behaviour

Hi,
That's not possible at this moment because there is a single value for both. In any case, could you open a separate issue to extend and track your use case?