exec cannot read stdout/stderr data after stdin reaches EOF

[esw-amzn]

Current and expected behavior

I'm trying to implement a tool for my application that has similar behavior to kubectl exec. I've encountered an issue when piping data to stdin. As soon as stdin is closed the Rust client closes both stdin and stdout streams and there is no way to get any remaining stdout data.

The equivalent kubectl command would be something like this.

$ echo hello world | kubectl -n my_namespace exec --stdin my_pod -- cat -
hello world

In this case "hello world" is properly echoed back. When I try the equivalent of this with my Rust tool using kube-client I never get the echoed response.

Possible solution

It appears the issue is with the break here. https://github.com/kube-rs/kube/blob/main/kube-client/src/api/remote_command.rs#L342

This break causes the entire message loop to shut down as soon as the end of stdin is reached. So it is not possible to get any remaining stdout/stderr data back after stdin is finished. It seems removing the break would fix the issue.

Looking at the Go client implementation, it appears that the Go implementation continues to read from stdout/stderr even after stdin is closed. https://github.com/kubernetes/client-go/blob/master/tools/remotecommand/v2.go#L183-L188

Additional context

No response

Environment

$ kubectl version
Client Version: v1.31.1
Kustomize Version: v5.4.2
Server Version: v1.30.8-eks-2d5f260

Configuration and features

k8s-openapi = { version = "0.24", features = ["v1_30", "schemars"] }
kube = { version = "0.98", features = ["runtime", "ws", "admission", "derive"] }

Affected crates

kube-client

Would you like to work on fixing this bug?

maybe

[clux]

Hey there. Thanks for this!

I think this makes sense to do. Would you like to submit a PR?
..it might be worth checking that it doesn't cause any other problems with the pod_ examples. They don't all run on CI, and we don't test that loop that deeply.

[esw-amzn]

I'll try an make a PR for this. It looks like the fix is more involved than just removing the break.