What causes "failed to stream pod logs for pod: %s, container: %s" in helm/helm?

Fetch logs directly to see the real cause: kubectl logs -c -n --previous.

failed to stream pod logs for pod: %s, container: %s

Error message

failed to stream pod logs for pod: %s, container: %s

What it means

Thrown by copyRequestStreamToWriter (pkg/kube/client.go:1308) when opening the log stream for a pod/container fails: the rest.Request.Stream call backing pod log retrieval (used by OutputContainerLogsForPodList to dump logs of non-ready pods when a --wait fails). Notably this error is formatted without %w — the underlying cause (404, 403, container not running) is discarded, so only pod and container names are reported.

Source

Thrown at pkg/kube/client.go:1308

	for _, pod := range podList.Items {
		for _, container := range pod.Spec.Containers {
			options := &v1.PodLogOptions{
				Container: container.Name,
			}
			request := c.kubeClient.CoreV1().Pods(namespace).GetLogs(pod.Name, options)
			err2 := copyRequestStreamToWriter(request, pod.Name, container.Name, writerFunc(namespace, pod.Name, container.Name))
			if err2 != nil {
				return err2
			}
		}
	}
	return nil
}

func copyRequestStreamToWriter(request *rest.Request, podName, containerName string, writer io.Writer) error {
	readCloser, err := request.Stream(context.Background())
	if err != nil {
		return fmt.Errorf("failed to stream pod logs for pod: %s, container: %s", podName, containerName)
	}
	defer readCloser.Close()
	_, err = io.Copy(writer, readCloser)
	if err != nil {
		return fmt.Errorf("failed to copy IO from logs for pod: %s, container: %s", podName, containerName)
	}
	return nil
}

// scrubValidationError removes kubectl info from the message.
func scrubValidationError(err error) error {
	if err == nil {
		return nil
	}
	const stopValidateMessage = "if you choose to ignore these errors, turn validation off with --validate=false"

	if strings.Contains(err.Error(), stopValidateMessage) {
		return errors.New(strings.ReplaceAll(err.Error(), "; "+stopValidateMessage, ""))

View on GitHub (pinned to 2a29f1770b)

Solutions

Fetch logs directly to see the real cause: kubectl logs <pod> -c <container> -n <namespace> --previous.
Grant pods/log to the identity if kubectl logs returns 403 for the same service account.
Treat this error as secondary: it occurs while reporting the primary --wait failure — fix the pod's readiness problem (image, probes, crashloop) first.
For flapping pods, collect logs via cluster-level tooling or kubectl logs -f since Helm's one-shot fetch may race pod deletion.

Example fix

# before: helm --wait fails, log dump errors with no cause
# 'failed to stream pod logs for pod: app-abc123, container: web'

# after: reproduce with kubectl to surface the real status
kubectl logs app-abc123 -c web -n default --previous
kubectl auth can-i get pods/log -n default

Defensive patterns

Strategy: try-catch

Validate before calling

// Skip log fetching for pods in terminal phases
for _, pod := range podList.Items {
    if pod.Status.Phase == v1.PodSucceeded || pod.Status.Phase == v1.PodFailed {
        continue // log stream for terminal pods may be unavailable
    }
    fetchLogs(pod)
}

Type guard

func isLogStreamError(err error) bool {
    return strings.Contains(err.Error(), "failed to stream pod logs for pod:")
}

Try / catch

if err := client.OutputContainerLogsForPodList(pods, ns, wf); err != nil {
    if isLogStreamError(err) {
        // note: Helm drops the cause here; fall back to direct kubectl logs
        // never mask the primary wait failure with this
    }
    return err
}

Prevention

Grant pods/log alongside pods/list in any role used with --wait.
Treat this error as diagnostic noise: always fix the underlying readiness failure shown by the primary --wait error.
For crashlooping jobs, collect logs with --previous or cluster log tooling instead of relying on Helm's one-shot dump.

When it happens

Trigger: helm --wait fails and Helm tries to print pod logs, but the stream fails: pod already terminated/evicted (logs unavailable for stopped containers in some runtimes), RBAC missing pods/log, container in CrashLoopBackOff with no log endpoint yet, or kubelet/apiserver log path errors.

Common situations: Debugging failed --wait installs where RBAC grants pods list but not pods/log; pods deleted between readiness check and log fetch; ephemeral/exit-early containers (jobs) whose logs are gone by fetch time.

Related errors

AI-assisted analysis of helm/helm@2a29f1770b (2026-08-15). Data as JSON: /api/errors/808c660e44c7cfdb. Report an issue: GitHub.