-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
client.Get() does not zero out slice fields on CRD objects #1639
Comments
Yeah, I can confirm this. This happens because the json deserializer (caseSensitiveJSONIterator) doesn't clear the object. I presume it works with the ConfigMap as expected because we use proto there. Seems we have to workaround this by resetting the value in at least Get() and List() |
Fixes kubernetes-sigs#1639 The json deserializer of the stdlib and the one from Kube which aims to be compatible won't zero out all field types in the object it deserializes into, for example it lets slices be if the json does not contain that field. This means that if a non-empty variable is used for any api call with the client, the resulting content might be a mixture of previous content and what is on the server. This PR adds a wrapper around the deserializer that will first zero the target object.
Fixes kubernetes-sigs#1639 The json deserializer of the stdlib and the one from Kube which aims to be compatible won't zero out all field types in the object it deserializes into, for example it lets slices be if the json does not contain that field. This means that if a non-empty variable is used for any api call with the client, the resulting content might be a mixture of previous content and what is on the server. This PR adds a wrapper around the deserializer that will first zero the target object.
Fixes #1639 The json deserializer of the stdlib and the one from Kube which aims to be compatible won't zero out all field types in the object it deserializes into, for example it lets slices be if the json does not contain that field. This means that if a non-empty variable is used for any api call with the client, the resulting content might be a mixture of previous content and what is on the server. This PR adds a wrapper around the deserializer that will first zero the target object.
Fixes kubernetes-sigs#1639 The json deserializer of the stdlib and the one from Kube which aims to be compatible won't zero out all field types in the object it deserializes into, for example it lets slices be if the json does not contain that field. This means that if a non-empty variable is used for any api call with the client, the resulting content might be a mixture of previous content and what is on the server. This PR adds a wrapper around the deserializer that will first zero the target object.
Fixes kubernetes-sigs#1639 The json deserializer of the stdlib and the one from Kube which aims to be compatible won't zero out all field types in the object it deserializes into, for example it lets slices be if the json does not contain that field. This means that if a non-empty variable is used for any api call with the client, the resulting content might be a mixture of previous content and what is on the server. This PR adds a wrapper around the deserializer that will first zero the target object.
I've encountered some unusual behavior when using Get() on CRD objects with the controller-runtime client. When the client.Object you pass into Get() has a slice field populated with values and the object on the API server has an empty or nil slice for that field, the client does not properly zero/empty that field.
This is in contrast with the behavior when getting core objects, which does zero/empty fields as expected.
Observations
The example test below demonstrates the inconsistency.
The text was updated successfully, but these errors were encountered: