Report

When the Azure Event Hub trigger sets unprocessedEventThreshold to 0 (explicit string "0" in trigger metadata), KEDA’s typed config accepts it (the default 64 is only applied when the key is missing or empty, not when the value is "0"). During metric collection, getTotalLagRelatedToPartitionAmount divides the total unprocessed event count by that threshold with no guard, which causes an integer division by zero and a runtime panic in Go.

There was no validation at scaler construction time comparable to other lag-based scalers (e.g. Kafka’s lagThreshold validation).

Expected Behavior

Scaler creation or validation should fail fast with a clear error (for example that unprocessedEventThreshold must be a positive number), consistent with scalers such as Kafka that reject non-positive lag thresholds. Scaling should never panic because of this setting.

Actual Behavior

The Azure Event Hub scaler could be created successfully with unprocessedEventThreshold: "0". The first execution path that computed lag and called getTotalLagRelatedToPartitionAmount(..., threshold=0) could panic (divide by zero), which can disrupt metric collection / the operator or metrics path depending on where the panic propagates.

Steps to Reproduce the Problem

Logs from KEDA operator

example

KEDA Version

2.19.0

Kubernetes Version

None

Platform

None

Scaler Details

azure event hub scaler

Would you be open to contributing a fix?

Yes

Anything else?

I will follow up with a fix shortly