Steven Hawkins

> No, this hasn't been fixed but not sure how important it is It's just a nice to have for completeness.

You have a dependency issue - a conflicting version of kubernetes-model-common is being used in your project.

I cannot reproduce this locally with maven or gradle. It seems like you have a constraint in your project that is forcing the downgrade.

@meileinb the project in question is using gradle. If it were using maven the above is not necessary - the 5.12 and 6.0 intra-project dependencies are correct.

Ideal state is: * deprecate/remove: DefaultKubernetesResourceList, CustomResourceList, and KubernetesResourceList * BaseKubernetesList becomes generic (and thus a replacement for CustomResourceList and DefaultKubernetesResourceList) and the generation logic is changed to make each...

@aleboulanger with 6.0 the core of the client and 2 of the http client implementations (jdk and jetty) are mostly reactive and make conservative use of threads - the okhttp...

Can you provide what the dsl call looks like leading up to the exec? I can reproduce similar behavior if I omit handling for stderr: ``` ExecWatch execWatch = podResource...

It's probably this: https://github.com/jenkinsci/kubernetes-plugin/blame/master/src/main/java/org/csanchez/jenkins/plugins/kubernetes/pipeline/ContainerExecDecorator.java#L373 That has handling for error, so it's not the cause.

> how do we fix this Error? I'm not sure. - are there other entries in the log that seem related? - do you have a set of versions when...

> Later version of the k8s client (currently 5.12.2) does not solve the problem There have been some additional changes in 6, have you tried that as well? And possibly...