Redis Streams Scaler Does Not Trigger on a Single Message

[csabca83]

Description:

When using the Redis Streams scaler in KEDA, I’ve observed that scaling does not occur when there is only a single message in the queue. The scaling only happens when at least 2 messages are present, which is problematic for use cases where individual messages need immediate processing.

This behavior seems to be related to the logic in the Redis Streams scaler code, where the lag count is being checked.

Here is the trigger configuration I was using with v2.15.1:

  triggers:
  - type: redis-streams
    metadata:
      stream: messages
      consumerGroup: worker_group
      lagCount: "5"
      streamLength: "1"
      activationLagCount: "0"

and I had to change it to this one with v2.16.0 and v2.16.1:

  triggers:
  - type: redis-streams
    metadata:
      stream: messages
      consumerGroup: worker_group
      lagCount: "5"
      streamLength: "1"
      activationLagCount: "1"

Steps to Reproduce:

1. Configure a Redis Streams scaler with the above configuration.
2. Send a single message to the messages stream.
3. Observe that no scaling occurs when there is only one message in the stream.
4. Add a second message to the stream. At this point, scaling is triggered.

Expected Behavior:

Scaling should occur when there is a single message in the stream, as long as the lag count exceeds the activationLagCount (which is set to 0 in this case).

Actual Behavior:

Scaling only occurs when there are at least 2 messages in the stream, leading to delayed or missed processing for cases where only a single message arrives.

Additional Context:

This issue affects use cases where low-latency processing of individual messages is required. If any additional configuration is needed to support this behavior, it should be documented.

[rickbrouwer]

I think you are right. As I see it, this was accidentally created during a refactoring.
The documentation also states that a default of 0 is allowed and in version v2.15.1 that seems to be possible.
In v2.16 a check is applied where the value 0 is not allowed. That doesn't seem right to me.

The code contains the following line:

return []external_metrics.ExternalMetricValue{metric}, metricCount > s.metadata.ActivationLagCount, nil

The second return value (the boolean) determines whether the scaler is active. This becomes true if metricCount > ActivationLagCount.
Because ActivationLagCount cannot be 0, this means that there must be at least 2 messages before scaling is activated.

So that would explain your finding.

Is this something you want to look into? No worries if not, maybe I'll look into it for a fix.

[csabca83]

Hi @rickbrouwer ,

Thanks for your detailed explanation! That makes sense and explains my findings clearly. I’m pretty busy these days, but I’d really appreciate it if you could look into this for a fix when you have the time. Let me know if there’s anything specific you’d need from me to help with the process.

Thanks again!