-
Notifications
You must be signed in to change notification settings - Fork 295
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
🌱 lint: fix the JSON encoding check error via errchkjson linter #2273
🌱 lint: fix the JSON encoding check error via errchkjson linter #2273
Conversation
Hi @MrDXY. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
.golangci.yml
Outdated
errchkjson: | ||
check-error-free-encoding: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
errchkjson: | |
check-error-free-encoding: true |
We should not set this to be equal to CAPI and resolve the findings instead by handling the error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I can make the necessary adjustments here, and it totally makes sense that we prefer to keep consistent with CAPI.
To discuss it further:
This check-error-free-encoding
parameter here, is just to indicate the errchkjson
to ignore the errors that will never happen.
Especially in some cases:
sshKey, _ := json.Marshal(env.VSphereSSHAuthorizedKeysVar)
controlPlaneIP, _ := json.Marshal(env.ControlPlaneEndpointVar)
secretName, _ := json.Marshal(env.ClusterNameVar)
kubeVipPod, _ := json.Marshal(kubeVIPPodYaml())
the input of the json.Marsha()
is just a string, which will never cause the function to fail, IIRC. To handle such a situation, is it a good idea to propagate errors to the higher-level calling function? Or do you recall any recommended approaches that I could follow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did see that the required changes would only be in the flavorgen tool. So just bubbling them up should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to ask, just want to make sure, bubbing them up
means bubbling the error
up to the higher-level function, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. No worries, just ask all good :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. So keeping it as is is fine :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with keeping it as it's the consensus - but I don't really like relying on external linters like this for something this fundamental, at the cost of saving a few lines of if err == nil
'{}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point on relying on an external linter. Basically if they have a bug in their logic we inherit that in CAPI as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, changing my opinion again. Now I'm in favor of dropping the check-error-free-encoding
config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrischdi It's totally fine! Still, welcome any advice or suggestions you may have.
@sbueringer Got it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/ok-to-test
/lgtm /assign @killianmuldoon @chrischdi
See: #2273 (comment) |
/lgtm cancel |
ec6c555
to
b23ef2d
Compare
b23ef2d
to
27c14a9
Compare
27c14a9
to
2e2f203
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Thanks for this!
LGTM label has been added. Git tree hash: 4fc5dadd58eb94498c98ead0031f94e130941a92
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
Thanks!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chrischdi 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:
Approvers can indicate their approval by writing |
cluster := newClusterClassCluster() | ||
cluster, err := newClusterTopologyCluster() | ||
if err != nil { | ||
return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should return the error here
I think if we choose to handle the error we should propagate (bubble) it up the entire call hierarchy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have considered this previously, and I choose to return nil
for the following reason:
-
the function
ClusterTopologyTemplateKubeVIP() []runtime.Object
does not have a return value for the error, so I'll need to modify the API structure to fit it in. While this method ispublic,
I'm not sure if this will cause some trouble for other customers who might be using it to generate their templates. -
Since we know that this method will not actually produce an error (the
json-encoding
error is safe to ignore), it may be okay not to expose it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's also OK. If we consider it inappropriate to ignore the error. I can make some adjustments to the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, totally missed that 🤦
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make the adjustment to the func to add the error return parameter. I think for this sort of code it should be okay if we evolve it a bit over time (not sure if anyone apart from us is using this util / it's exported functions)
It just feels consistent to handle the error if we choose to handle it and not drop it one level up the call hierarchy :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah looks like Christian opened a PR already
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created #2274 so we don't forget to fix that.
In this case its way better to bubble up even if we currently know the current code does not produce an error.
There should either only be the two extremes:
- bubbling up
- or ignore the error where we get it, not somewhere in-between
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, all good
What this PR does / why we need it:
json.Marshal
)errchkjson
check in.golangci.yml
configuration file.linters-settings.errchkjson.check-error-free-encoding
. With it set to true, errchkjson does not report about the errors from json encoding functions that are safe to be ignored, because they are not possible to happen.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Part of #2058