Description

As discovered in kedacore#5962 (comment), the Eventually function of Gomega is meant to block when called and attempts an assertion periodically until it passes or a timeout occurs (docs).

This means we should be using it with polling functions such as Get to wait for an event to happen (example), but not functions such as Create unless we're intending to repeatedly try the creation until something different happens.

Our incorrect usage causes the existing tests to report false results, because in cases such as:

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

An error does occur here, but that's caused by the error resourceVersion should not be set on objects to be created since so gets modified in-place after the first create and we're trying to apply it again.

On the other hand, if we expect no error to occur with the create:

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

If the first Create passes, then the Eventually block also passes. In this case, there's no point having the Eventually since we're not waiting for anything.

Changes

As proof that this Eventually is not necessary and will only lead to false positives, I've tried removing the wrapper from all places where it's called with a mutating Create or Update call. With this change, the tests still pass.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

Relates to #