-
Notifications
You must be signed in to change notification settings - Fork 26
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
Fix nil interface{} checks #1459
Conversation
🤖 Created branch: z_pr1459/tpantelis/fix_nil_checks |
PR submariner-io#1447 changed places where we check for nil interface{} in the callback functions for AwaitUntil to cast first. However this can result in an invalid type conversion panic depending on how the value is returned from the operation function. In Go, an interface var contains both a type and value so there are 2 cases for a nil: 1) The type is non-nil and the value is nil 2) The type and value are nil For #1, the interface{} var is not actually nil so checking 'if result == nil' yields false. Eg, var s *string var i interface{} = s if i == nil { // yields false b/c i is typed } In this case, we can cast to the expected type and then check for nil. s := i.(*string) if s == nil { // yields true } For #2, the interface{} var is untyped so nil check yields true: var i interface{} = nil if i == nil { // yields true } So in cases where we directly return nil from an operation function, the nil check in the result function is valid. The actual reason for submariner-io#1447 was b/c of a nil pointer panic in AwaitGatewaysWithStatus. This function was previously changed to call 'findGateway' and return its values. However 'findGateway' returns *unstructured.Unstructured so now the operation function returned a typed interface{} var. So if 'findGateway' returns a nil *unstructured.Unstructured value, the 'result == nil' check in the result function yields false. This resulted in the panic when 'result' was later casted and accessed. So we basically need to undo submariner-io#1447. For AwaitGatewayWithStatus and AwaitGatewayFullyConnected, check the error from 'findGateway' and return a nil interface{} value. Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
b543683
to
ef86784
Compare
The globalnet w/ helm job is failing:
Need to update the helm chart to add |
🤖 Closed branches: [z_pr1459/tpantelis/fix_nil_checks] |
PR #1447 changed places where we check for nil
interface{}
in the callback functions forAwaitUntil
to cast first. However this can result in an invalid type conversion panic depending on how the value is returned from the operation function. In Go, an interface var contains both a type and value so there are 2 cases for a nil:For 1, the
interface{}
var is not actually nil so checkingif result == nil
yields false. Eg,In this case, we can cast to the expected type and then check for nil.
For 2, the
interface{}
var is untyped so nil check yields true:So in cases where we directly return nil from an operation function, the nil check in the result function is valid.
The actual reason for #1447 was b/c of a nil pointer panic in
AwaitGatewaysWithStatus
. This function was previously changed to callfindGateway
and return its values. HoweverfindGateway
returns*unstructured.Unstructured
so now the operation function returned a typedinterface{}
var. So iffindGateway
returns a nil*unstructured.Unstructured
value, theresult == nil
check in the result function yields false. This resulted in the panic whenresult
was later casted and accessed.So we basically need to undo #1447. For
AwaitGatewayWithStatus
andAwaitGatewayFullyConnected
, check the error fromfindGateway
and return a nilinterface{}
value.