kmeshctl dump continues after port-forward failure and does not close the forwarder

[yash-pakhale-07]

What happened:

kmeshctl dump logs an error when port-forward startup fails, but continues and issues an HTTP request to the local forwarding address. It also does not call fw.Close() after a successful port-forward start.

This differs from kmeshctl log, kmeshctl version, and kmeshctl monitoring, which stop on Start() failure and defer fw.Close().

What you expected to happen:

kmeshctl dump should:

1. Stop immediately when fw.Start() returns an error.
2. Call fw.Close() after a successful start, including on HTTP or parsing failures.

How to reproduce it (as minimally and precisely as possible):

1. Configure kubectl access to a cluster.
2. Run kmeshctl dump with a daemon pod for which port-forwarding cannot start, for example:

kmeshctl dump nonexistent-kmesh-daemon kernel-native

3. Observe that the command logs the port-forward startup error, then proceeds to issue the HTTP request and may log a second, less useful HTTP connection error.

Code path:

• ctl/dump/dump.go, RunDump(): logs fw.Start() failure but does not exit/return; immediately calls http.Get.
• pkg/kube/portforwarder.go, Close(): cancellation is only performed when callers invoke fw.Close().
• ctl/log, ctl/version, and ctl/monitoring: each exits/returns on start failure and uses defer fw.Close().

Anything else we need to know?:

The process normally exits shortly after command completion, so the unclosed forwarding session is generally bounded by process lifetime. However, RunDump() does not manage its own forwarding lifecycle and can leave the forwarding goroutine/context active while the process remains alive or when reused in-process.

Suggested fix:

if err := fw.Start(); err != nil {
    log.Errorf("failed to start port forwarder for Kmesh daemon pod %s: %v", podName, err)
    os.Exit(1)
}
defer fw.Close()

This should be suitable as a small standalone PR, ideally with tests for failure short-circuiting and cleanup.

Environment:

• Kmesh version: Not specified
• Kmesh mode: Affects both Kernel-Native and Dual-Engine modes
• Istio version: Not specified
• Kernel version: Not specified
• Others: Reproducible from the CLI control flow; requires Kubernetes access where port-forward startup fails.

[Udaytaneja]

Hi mantainers , I am interested in doing this work . Please assign this to me .