-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
🐛 Conversion webhook should not panic when conversion request is nil #1970
🐛 Conversion webhook should not panic when conversion request is nil #1970
Conversation
|
Welcome @Tomy2e! |
Hi @Tomy2e. 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. |
/ok-to-test |
@@ -69,6 +69,12 @@ func (wh *Webhook) ServeHTTP(w http.ResponseWriter, r *http.Request) { | |||
return | |||
} | |||
|
|||
if convertReview.Request == nil { | |||
log.Error(nil, "conversion request is 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.
Should this be an info instead of 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.
I think Error should be used as we're logging an error message here. Also the documentation says "Info logs a non-error message with the given key/value pairs as context" so it may not be appropriate to use Info. What do you think?
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.
Error seems okay to me. It definitely seems to fall in the same category as l.67
if err != nil {
log.Error(err, "failed to read conversion request")
w.WriteHeader(http.StatusBadRequest)
return
}
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.
Problem is that we're passing nil
to log.Error
which seems a bit backwards, let's either create an error, or spit out an Info as warning for users?
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.
Maybe
log.Error(errors.New("conversion request is nil"), "failed to handle conversion request")
?
Still feels a bit strange, but maybe better than logging one error as an error and the other as info
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 don't see any issue with err being nil
, the docs clearly say this is ok (https://pkg.go.dev/github.com/go-logr/logr#Logger.Error and https://github.com/kubernetes-sigs/controller-runtime/blob/master/TMP-LOGGING.md#logging-errors).
Also, there are already many instances of Error being called with a nil
error in this repo (https://github.com/kubernetes-sigs/controller-runtime/search?q=log.Error%28nil)
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.
We went through multiple logger iterations before we got here, but anyways, that's fine if we want to log Error
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Tomy2e, vincepri 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 |
/retitle 🐛 Conversion webhook should not panic when conversion request is nil |
This PR fixes a panic in the conversion webhook HTTP handler when no conversion request is sent by the client.
To avoid dereferencing a nil pointer when trying to access the UID, I set a default uid to an empty UID.
Let me know if I should return an HTTP Bad Request instead.
EDIT: Bad Request is returned when the conversion request is nil