Skip to content
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

Type Assertion Paranoia #121

Conversation

JustinKuli
Copy link
Member

While working on https://issues.redhat.com/browse/ACM-4309, I found a few more spots where it's hard to tell if type assertions could panic... well, now it's easier, because in these instances, it definitely can't anymore.

A helper function helps ensure this is handled more consistently, and
more safely.

Refs:
 - https://issues.redhat.com/browse/ACM-4309

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
Copy link
Member

@dhaiducek dhaiducek left a comment

Choose a reason for hiding this comment

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

This is wayyyyyy cleaner overall--nice work!!! There's a fmt/linting failure in the CI, though.

This real type removes the need for type assertions in the
`createInformStatus` function.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
Copy link
Member

@dhaiducek dhaiducek left a comment

Choose a reason for hiding this comment

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

There's a failing unit test now?

This may help performance slightly, and removes the need for some type
assertions in the `mergeArrays` function.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
Copy link
Member

@dhaiducek dhaiducek left a comment

Choose a reason for hiding this comment

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

These are some really nice improvements. I have one comment to consider about the sorting logic.

controllers/configurationpolicy_utils.go Outdated Show resolved Hide resolved
controllers/configurationpolicy_utils.go Outdated Show resolved Hide resolved
if !checkFieldsWithSort(mVal, oldItem[i].(map[string]interface{})) {
return false
if oVal, ok := oldItem[i].(map[string]interface{}); ok {
return len(mVal) == len(oVal) && checkFieldsWithSort(mVal, oVal)
Copy link
Member

Choose a reason for hiding this comment

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

Would it need to return false after this since ok would have failed, similar to above?

Copy link
Member Author

Choose a reason for hiding this comment

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

Probably. Good catch.

I started to get distracted making all of these kinds of things more consistent... but I think that it needs more attention than I can give it right now. It is probably due for some refactoring to reduce some repeated logic like length checks before and in checkListsMatch. So, maybe that's a future item.

Some of these may be bordering on paranoia, and my search was not
totally exhaustive... but this should make me feel a little bit safer.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
@openshift-ci
Copy link

openshift-ci bot commented Apr 13, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhaiducek, JustinKuli

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [JustinKuli,dhaiducek]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

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

Successfully merging this pull request may close these issues.

3 participants