Skip to content

Add error and event for mismatching input property #6763

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

SpiritZhou
Copy link
Contributor

Provide a description of what has been changed

Checklist

Fixes #

Relates to # #6721

zhenghanzhou added 2 commits April 29, 2025 15:45
Signed-off-by: zhenghanzhou <[email protected]>
Signed-off-by: zhenghanzhou <[email protected]>
@SpiritZhou SpiritZhou requested a review from a team as a code owner May 7, 2025 02:12
Signed-off-by: zhenghanzhou <[email protected]>
Copy link
Contributor

@dttung2905 dttung2905 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally LGTM, just a small nit though

message := fmt.Sprintf("Unmatched input property %s in scaler %s", key+suffix, sc.ScalableObjectType)
// Just logging as it's optional property checking and should not block the scaling
logger.Error(nil, message)
sc.Recorder.Event(sc.ScaledObject, corev1.EventTypeNormal, eventreason.KEDAScalersInfo, message)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use corev1.EventTypeWarning instead of corev1.EventTypeNormal here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see a good rationale for either type. My usual rule of thumb is

  • use Normal when something successfully happened and a user should know about it - e.g. volume is mounted, some connection was established...
  • use Warning when something unexpected happened and it has negative impact for the user - e.g. volume didn't get mounted, some connection got broken...

This case "an extra parameter user provided is ignored". KEDA is successful at ignoring it but it might have unexpected result for the user, so a bit of both. I'd probably also pick Warning event but I can be easily convinced for Normal.

@wozniakjan
Copy link
Member

wozniakjan commented Jun 9, 2025

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

Copy link
Member

@wozniakjan wozniakjan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thank you!

Maybe the event type deserves a little bit of discussion as mentioned here by @dttung2905 but I'm happy with either result of the discussion.

@SpiritZhou
Copy link
Contributor Author

SpiritZhou commented Jun 11, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants