Optional field Operation is now mandatory in Azure Service Bus scaler

[connorbullard]

Report

There was recently a refactor done in azure_servicebus_scaler released in 2.17 that appears to have accidentally removed the logic setting a default value for operation when it is not provided. Previously, parseAzureServiceBusMetadata contained this logic:

...
	meta.operation = sumOperation
	if meta.useRegex {
		if val, ok := config.TriggerMetadata["operation"]; ok {
			meta.operation = val
		}

		switch meta.operation {
		case avgOperation, maxOperation, sumOperation:
		default:
			return nil, fmt.Errorf("operation must be one of avg, max, or sum")
		}
	}
...

However, when logic was remove from this method and migrated to Validate, it appears that this was not carried over or reimplemented elsewhere. As a result, when useRegex is set to true, unless a value for operation is provided with the trigger, all checks via performOperation will permanently result in 0 messages being returned as there is no default case in the switch statement.

Expected Behavior

Per the documentation, if a user does not specify an operation value in their trigger a default value (sum) should be assigned and used in determining whether a threshold is hit.

Actual Behavior

Because of this bug, without operation being specified in the deployment the actual message count will never be retrieved when useRegex is set to true.

Steps to Reproduce the Problem

1. Create a scaledobject deployment with the azure-servicebus as a trigger using Keda 2.17, provide the queueName regex pattern, messageCount, and set useRegex to true but leave operation undefined.
2. Deploy the scaledobject and put messages on any queues matching the regex pattern.
3. Observe that scaling does not occur even when the message count exceeds the threshold set by the deployment.

Logs from KEDA operator

No response

KEDA Version

2.17.0

Kubernetes Version

1.30

Platform

Microsoft Azure

Scaler Details

Azure Service Bus

Anything else?

Because this silently fails to scale, this could cause serious issues with production deployments on the latest Keda that do not account for operation.

[rickbrouwer]

Thanks for the report! I have created a fix (#6731)

[connorbullard]

Thanks @rickbrouwer for the quick help here!