Regarding tests:

The test case for the webhook rejecting invalid fallback is done here. However, this was falsely passing before due to the section:

	Eventually(func() error {
		return k8sClient.Create(context.Background(), so)
	}).Should(HaveOccurred())

According to Gomega docs, Eventually blocks when called and attempts an assertion periodically until it passes or a timeout occurs. In this test case, we are repeatedly trying to create a new ScaledObject, and previously the first create would pass but the second create would fail with resourceVersion should not be set on objects to be created, since the first create made an in-place update of so and added resourceVersion metadata.

Is there a reason we are wrapping this assertion in an Eventually block? I don't see why this needs to poll or be run asynchronously.

The whole scaledobject_webhook_test.go file uses Eventually in most of its tests, but I believe they can be simplified into just

	err = k8sClient.Create(context.Background(), so)
	Expect(err).ToNot(HaveOccurred())

Awesome catch! In theory, the addmission webhook must block invalid SO, so I think that the fix isn't a breaking change (@tomkerkhove @zroubalik ?) Could you update the test to ensure that the behaviour is correctly covered by tests?

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

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

Rebased onto main due to a merge conflict with the changelog.

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

PTAL @wozniakjan

What if there is some scaler that supports fallback (eg. Prometheus) and also CPU/Memory scaler?

imho ideally KEDA should allow this, looks like this PR would make it not possible while in previous versions it just logged as an error?

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.

This issue has been automatically closed due to inactivity.