Pass deepCopy objects to the polling goroutines

[zroubalik]

Signed-off-by: Zbynek Roubalik zroubali@redhat.com

Pass deepCopy of ScaledObject/ScaledJob objects to the scaleLoop polling goroutines it's a precaution to not have global objects shared between threads.

It should potentially help with the issue, which occurs if there is a big number of scalers running. Sometimes there are periodic panics in the json Marshall code that appeared to be related to passing the scaler objects to the background go routines and causing race conditions between fetching and serializing in different goroutines.

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Changelog has been updated

[coderanger]

I'm not 100% sure this will fix the bug we talked about but I think it's definitely good to do no matter what. Down with mutable global state!

[coderanger]

Actually as I'm looking at this harder, do we want to copy them here or at the point we actually launch the goroutines?

keda/pkg/scaling/scale_handler.go

Lines 104 to 105 in 347e897

	go h.startPushScalers(ctx, withTriggers, scalableObject, scalingMutex)
	go h.startScaleLoop(ctx, withTriggers, scalableObject, scalingMutex)

I think the way this is now, both goroutines would get the same reference.

[zroubalik]

Actually as I'm looking at this harder, do we want to copy them here or at the point we actually launch the goroutines?

keda/pkg/scaling/scale_handler.go

Lines 104 to 105 in 347e897

	go h.startPushScalers(ctx, withTriggers, scalableObject, scalingMutex)
	go h.startScaleLoop(ctx, withTriggers, scalableObject, scalingMutex)

I think the way this is now, both goroutines would get the same reference.

Yeah, you are right, that's much better spot. Let me change that.

[coderanger]