You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The data returned by KubernetesObjectApi.list() does not deserialize timestamps in the items[].metadata field which makes the results inconsistent with KubernetesObjectApi.get(). As a result, the returned manifests cannot directly be used with the KubernetesObjectApi.patch() method because the string-based timestamps will be rejected.
This issue might be related to the changes in #1695.
Client Version 0.22.1
Server Version v1.30.5
Steps to Reproduce & Example Code
The following code snippet reproduces the problem. The code tries to list VirtualServices and thus requires istio to be installed. However, the problem can be reproduced with any other resource kind that is not known to the kubernetes/client-node package.
import{KubeConfig,KubernetesObjectApi}from'@kubernetes/client-node';constTEST_RESOURCES={VirtualService: {apiVersion: 'networking.istio.io/v1',kind: 'VirtualService',namespace: 'default',name: 'my-service',},Pod: {apiVersion: 'v1',kind: 'Pod',namespace: 'default',name: 'my-pod',},};(async()=>{constkc=newKubeConfig();kc.loadFromDefault();constclient=KubernetesObjectApi.makeApiClient(kc);// const { apiVersion, kind, name, namespace } = TEST_RESOURCES.Pod; // known resource kinds work as expectedconst{ apiVersion, kind, name, namespace }=TEST_RESOURCES.VirtualService;// "unknown" resource kinds have inconsistent timestamp typesawaitclient.list(apiVersion,kind,namespace);constpod1=awaitclient.list(apiVersion,kind,namespace).then((response)=>response.body.items.find((p)=>p.metadata?.name===name)!);constpod2=awaitclient.read({ apiVersion, kind,metadata: { namespace, name }}).then((response)=>response.body);// Types of timestamps will be different when listing VirtualServicesconsole.log(pod1.metadata?.creationTimestamp,pod1.metadata?.creationTimestamp?.constructor.name);console.log(pod2.metadata?.creationTimestamp,pod2.metadata?.creationTimestamp?.constructor.name);console.log();})();
Expected behavior
The above code should print the same line twice, e.g.:
2023-07-19T12:59:47.000Z Date
2023-07-19T12:59:47.000Z Date
However, when listing VirtualServices (or any other resource that isn't known to this package) the timestamp types in the metadata are different, e.g.:
2023-07-19T12:59:47Z String
2023-07-19T12:59:47.000Z Date
Environment:
Probably happens on any environment. For completeness, this is my test environment:
OS: MacOS
NodeJS Version: 18
Cloud runtime: GKE
The text was updated successfully, but these errors were encountered:
LFrobeen
changed the title
Inconsistent deserializing when using KubernetesObjectApi.list vs KubernetesObjectApi.get
Inconsistent deserialization behaviour when using KubernetesObjectApi.list vs KubernetesObjectApi.getNov 8, 2024
Describe the bug
The data returned by
KubernetesObjectApi.list()
does not deserialize timestamps in theitems[].metadata
field which makes the results inconsistent withKubernetesObjectApi.get()
. As a result, the returned manifests cannot directly be used with theKubernetesObjectApi.patch()
method because the string-based timestamps will be rejected.This issue might be related to the changes in #1695.
Client Version
0.22.1
Server Version
v1.30.5
Steps to Reproduce & Example Code
The following code snippet reproduces the problem. The code tries to list
VirtualServices
and thus requires istio to be installed. However, the problem can be reproduced with any other resource kind that is not known to the kubernetes/client-node package.Expected behavior
The above code should print the same line twice, e.g.:
However, when listing
VirtualServices
(or any other resource that isn't known to this package) the timestamp types in the metadata are different, e.g.:Environment:
Probably happens on any environment. For completeness, this is my test environment:
The text was updated successfully, but these errors were encountered: